Stopping endless technical discussions and making a decision

Question

I always come across people who like to bang on for ages over the smallest "technical things".

Don't get me wrong, I'm a geek programmer who loves what I do, but you know the type of conversation.

• Mac is so much better than Windows
• Don't use a For Each loop, use a While loop
• Don't buy an Intel based PC, get an AMD based one.
• We should use one IoC container over another.

All these "things" have valid pro's and con's for both sides, and you'll never get a "correct" answer, and the person will never concede the point. (of course there will be some where there is an answer, maybe :).

My question (I'm getting there!!) is: In a software team, how do you cut through these long discussions without inhibiting innovation, so that a decision can be made and you can get on to solving the real business problems.

Answer 1

Problem 1. Some people don't like to lose. If they're not calling the shots, they're going to debate until they call the shots through attrition.

Problem 2. Nothing's really at stake, so debating is tolerated.

Nothing's at stake? Yes. Most of the decisions have almost zero dollar impact. The fact that it comes down to "bang on for ages" means that both choices are effectively identical.

What to do?

1. Realize that nothing's at stake.

2. Realize that in 2 or 3 years, the whole subject will be reopened because something outside the organization changed.

3. Toss a coin. Seriously. Just pick something and move on. Some folks will see the silliness in debating. Some folks will then debate the nature of the coin being tossed. If folks can't be satisfied with a coin toss, they have ego problems and need to learn that (a) nothing's at stake and (b) the decision will be changed in a few years.

If they can't figure out that nothing's at stake, they need to write out the dollar value of both sides of the argument. At some point, someone may see that more man-hours are being spent on analysis than the actual decision is worth. A coin toss produces equal value for a lower cost.

Answer 2

A couple of things to contemplate:

1. Only accept arguments that are quantifiable. If someone says it will save time ask them to quantify it and hold them to the answer. This way if they're talking rubbish they only get one go at it before everyone knows that they're a busted flush.

2. Get people to take responsibility for their recommendations. Make it clear that at the end of the year if they've been making bad calls that will be part of their appraisal. I don't mind debates but I want people with the courage of their convictions - if you're going to swear something is great and expect us to adopt it, you'd better be able to live with the consequences.

These are real things to get away from S.Lott's two problems - that some people don't like to lose and that nothing is at stake. My response is put something at stake so there is no debating for debating's sake.

Answer 3

1. Timebox the discussion. - If it takes more than 5 minutes for each side to state their case, then it's too complex. We actually use kitchen timers for this. They work wonderfully, and cost about 5 dollars.
2. Require that the participants argue with data and experience.
3. We keep the options on the table. After each side has their time, we spend another 5 minutes discussing the implications of each approach. After 20 minutes, we go out and do it (implement it). If it doesn't work, then we go with the other approach.

Answer 4

The rule is simple. Once you don't know what to choose - think what is better for the company.

Yes, Intel v AMD choice is not that easy. But which is better for your company? For example, if there's a person who is responsible for ordering stuff and it'll take him ages to order an AMD processor based PC, but Intel based can be ordered in a minute and you really don't care what it'll be - just order an Intel based one because it is better for the company.

Answer 5

Usually these discussions are really just bikeshedding. People arguing which transfer format or which data store to use and tons of other details which should be really transparent to all components but the one implementing the very detail. Nobody gives a damn as long as the component fulfills the design contract and those in charge of it will be able to respond to contract changes in a reasonable amount of time.

The vast majority of all technical problems you encounter in software development are bikeshedding problems. Simply because they already have solutions and the only question is, which solution you want to pick.
You should not lock yourself into such decisions. You should lock out such decisions into an abstraction layer that decouples your application from such details.
The really important problems in software development are design problems at feature and system level. Everything else is secondary.

So don't really even start such debates. Focus your energy in dividing your project into independent parts. This yields software, that is more robust and flexible. And should you be able to pinpoint technical decisions that have clear disadvantages (something you can only do, once you have a running software), then you can make a different decision without affecting the rest of the system.

Answer 6

Standardisation is one approach

Your team must come to a concensus on what they will adopt as their standard for development and then stick to it for a reasonable period of time (decided by the team). If the standard fails, then a new one is adopted probably from a new batch of possible solution frameworks.

"Hey, those PCs were useless in the end, let's try Macs!"

or

"I told you so! Spring is much better than EJB."

And so on.

Having a standard means that code becomes easier to work with across a team which in turn leads to a more productive environment.

Answer 7

I'm currently testing approach, code named "Papal conclave" and its quite promising. It is based on a story, that during one of the Papal elections there was a "deadlock" and cardinals simply could not make a choice. Entity hosting a election (most probably some City major) first locked cardinals in a building, then drastically reduced food supply and then removed roof of the building to make debating even less comfortable. As expected cardinals made the choice after roof was removed ending a three year deadlock.

So my approach is that when people disagree on some stuff, they are forced to discuss it untill they come up with a choice. I don't provide any other discomfort, not even a time constraint and of course I don't do anything with the roof :). All I do is constantly bring the issue up every day. If someone goes "We can't make a decision" i respond with "Well... you have to". So far I haven't met a person so hopelessly addicted to some minor technological detail that much. After a bunch of meetings they tend to look for a compromise just like cardinals.

I agree that this is more of a sustaining discussion, rather than cutting through it. However discussions aren't endless and as a plus, some people after such "conclave" tend to avoid minor technological debates, which makes things more comfortable for the entire team.

Answer 8

I've read somewhere than you should not travel more than 6 together if you need to agree on where you are to go and what to do, as you will not reach consensus.

This is a prime example of why there needs to be a person with decisive powers. In this particular example, said person needs to make a decision and say "it needs to be like this", and the others need to respect that decision so real work can be done.

If the decision then proves to be bad later, you at least knows for sure, and can learn from it.

Answer 9

One approach is by vote and works well in smaller sized teams.

While two individuals may be having the conversation; move it to an open forum...debate for N amount of time then hold a vote by raising hands.

Simple yet democratic and allows you to move forward.

Answer 10

A similar question could be:

How to stop religious/flame wars on forums?

I think @S.Lott is right in his comment, if the only point is "discussion", "walking away" or otherwise ignoring it might be the only answer. I've used that technique in the past.

If the point is to come to a solution, weigh pros/cons for the domain in question, set a time limit and (nods to Nike) just do it.

Answer 11

Ideally - IMO - the tech lead or authority figure says, "okay, thank you for your points, we're..." sound of dice roll "...going with so-and-so's idea." and everyone goes and sits down.

Geekery over minuscule points has wasted an enormous amount of my meeting time, and I don't want to hear it any more. :-/

Answer 12

I find that when you focus the conversation not on which alternative is right but on what the consequences of choosing the wrong one are, you tend to not get too bogged down. If we can come to a consensus that even if A is right, B won't kill us, nobody gets too butthurt if we end up going with B. If we can't come to that consensus, it's generally because there's a real problem that we have to address.

Answer 13

The main thing is that we have to be mature, and understand that we can't always agree with each other, the big and mature thing is to learn from each other, why we have the positions we have, and perhaps related to my own question, learn what experiences and the reason why. Then we can make up our own informed opinion and be damned or not.

I personally do not need or expect other people to agree with me, it would be nice, but not important. And to this point, I quote Voltaire.

"I may disagree with what you say, but I'll defend to the death, your right to say it." -Voltaire, 5th Century Philosopher

Answer 14

Every meeting should have a chairperson responsible for the agenda and keeping order (and taking minutes, although they can delegate this task to someone else if the meeting is too big for them to handle everything). The chairperson's task is to tell somebody to stop arguing ("guys, please take it offline" in corporate speak).

If the meeting is not worth appointing a chairperson, it is not a meeting worth having. You might just as well have a chat at the watercooler.

One can say "easier said than done, quant_dev". Well... a natural chairperson is a team leader, a project manager, a team manager. They should have the necessary authority. Meetings where nobody knows who's really leading the meetings are signs of chaos in the organisation, a deeper problem which needs to be solved.

Answer 15

Solve the general issues first: we need a web server, app server, DB, etc.

For the debates about which DB or server to use, park those items for another meeting.

During the subsequent meetings, allow for discussion to "short list" the potential offerings e.g. MySQl, MS SQL Server, Postgres, etc.

Allow team members to voice their opinions, but request that they back them up with facts. Product X sucks! Doesn't cut it, Product Y doesn't scale! Is too vague. Etc.

Once all the details are out and on the table you need to either put it to a vote or as team lead make an executive decision.

If you need to to flush out a clear winner or confirm support/lack of for a feature/concept feel free to take some time to do a POC (Proof Of Concept) but realize this will take time and there is a tendency for developers to want to run with whatever they have started with... Be sure to verify any roadblocks/tech concerns before going with the POC.

Answer 16

As a team-leader, I feel it depends if the decision must be made here and now.

If it must then I look for the one with the lowest cost of reversal. It is always important, as a development team, to know that your decision may be wrong, you may have to make the ballsy choice and change your minds. The cost of doing so should always be minimised.

If it can wait then consider the fact that neither of the parties disagreeing are in possession of all the facts. Ask them to walk away and research further and do your own research.

Do we always do this in the heat of battle? No, particularly when I'm one of the ones with a heated opinion (I don't claim to be perfect). But I do think that this is the way to approach such situations. Time-boxing never seems to lead to everyone agreeing, it just leads to an unconcluded argument.

Answer 17

Unless you have a difficult team member, you usually don't have endless debate unless there is no clear advantage to either approach. The following are some good approaches for breaking a tie:

• Let the person who actually has to implement it decide.
• For UI issues, let the person most aware of customer requirements decide.
• Let the person with the most experience on the subject or part of the code base decide.
• Let the person with the strictest schedule constraints or manpower and resource limitations decide.
• Let the person decide who has more concrete rather than theoretical objections.
• Find a compromise between the approaches.
• Gather more information and decide at the next meeting, giving more weight to people who obviously spent some time researching since the last meeting.

As far as how to announce a decision, you just say, "Okay, we're going with this because of this." If people feel like you have given them a fair hearing, and you are not wishy washy as a leader, they will go along with your decision. For the particularly stubborn, you can promise to reevaluate after a certain amount of implementation has been done, but most people will drop it by that point.

Answer 18

A good meeting facilitator can facilitate these kinds of discussions without letting them get out of hand.