I've listened to, and been a part of, no shortage of arguments about the technical merits of a particular programming solution. I've seen two (or more) developers argue about the way to solve a particular problem for hours, even days at times. The Internet is full of discussions and debates in forums on the "best" way to write code for all sorts of specific issues.

These arguments are sometimes referred to as religious wars for the devotion and belief that each proponent has in their solution. I tend to try and avoid becoming embroiled in any sort of zealotry as I am always cognizant of the fact that I need to be effective. I need to get things done and can't spend a lot of time arguing about a solution, whether for or against it. i need to get work completed.

When I was managing people I tried to limit the devolution of my staff into a never ending argument, but I ran across a better solution recently. Al Shalloway wrote a blog about limiting discussions to five minutes. He notes that two level-headed people ought to be able to come to a consensus in five minutes. Beyond that he says it's likely that one of them is arguing about covering possibilities rather than current realities.

That's interesting, and like many rules, I'm sure there are exceptions. A manager can make a decision to continue a discussion if they really think that it is warranted. However as a default, the idea that a team should choose the easiest solution to implement if they can't decide makes sense. It's the least amount of work that might be wasted, and we want to avoid wasting time and work when we can.

We won't always agree, and despite our best intentions, we will make mistakes and we will make poor decisions. Don't let indecision continue indefinitely and don't rashly make decisions, but don't let the fear of mistakes prevent you from choosing a path. Be decisive and move forward, adjusting as you learn more that helps you refine your solution.