Question

I believe that software decisions should be reached only if excepted and agreed by the team.
But most cases it varies.

How would you describe the way that decisions are being made in software development cycle in your company?
Is it Democracy? / Is it Dictation? / Is it Anarchy?

Here is what I heard from one of my friend:
“This is not democracy, I am the manager, I decide what to do”.

What do you think?

Answer 1

Summing up the answers so far – for any team, the decision making process must balance timeliness with accuracy. Any team needs:

• To make the right decision – in terms of potential bugs, difficulty to maintain, ability to meet requirements, ability to adhee any other process, quality, securty, etc. concerns.
• To make a consistent/well-communicated decision – almost always, making a decision one way in one place and another way in a different place will introduce some pretty painful bugs. These are likely to be expensive bugs, particularly in design decisions.
• To make a timely decision – very often, no decision at all is worse than the wrong decision. Often there are two different viable architectures/designs. One may be distinctly better given the requirements, but both might be doable. In those cases, even making the wrong decision is better than making no decision at all.

The process for the decision has to then reflect the needs of the team and the company. I’ve seen a pretty big variety here, even within the same company. Factors have included:

• Size of team – after the team grows to more than 3-5 people, you can no longer make decisions as a group. This is a human-based small group limitation. It’s very hard to have an effective meeting with a headcount over 5. If you can’t effectively talk, you can’t make a joint decision. This is where it will become necessary to appoint some leads and let them make the decision and comminicate to subteams, unless the decision can be made within a single team.
• Experience of team – in a team where only a very small percentage of the developers have prior experience with the related technology, it makes a degree of sense to isolate big decisions to the technology expert + the developer with problem domain knowledge. This fits with the idea of architects. Presumably, the architect has the better than average understanding of the technologies and technological risks, and he is in the best position to make the big decisions. This may not be so necessary if every developer has some degree of experience with the technology.
• Nature of product – if security, for example, is a big concern, there may need to be a separate group who’s only role is determining the security architecture. This area can be a big enough chunk of work that a single human brain cannot handle both security requirements and regular functional requirements.
• Degree of formal process – companies supporting critical applications or large applications may have some degree of rigour in their review process. Personally I prefer “peer reviews” to be the point where everyone vets the decisions made by a single person. If the decisions are controversial, it’s better to consider some other way of communicating before the thing being reviewed is finished.
• Team personality – Different teams work better with different management styles. I’ve seen situations where team members were unable to find compromise even after many months of working together. The happy team idea of “storming, norming, conforming, performinng” isn’t always acheivable in a specified time frame. In these cases, it’s going to fall on a senior level person with official power (like an architect or manager) to make decisions, because the team simply cannot make a decision any other way.

It’s my personal believe that teams work better when people feel they have had a stake in the decision. It’s much easier to put in 100% effort when you strongly believe that you had a hand in the big decisions that you are now stuck with. Software engineering is not drone work, and if people plod along without taking responsibility for decisions, they are only doing half the work, because they won’t be looking for the flaws in the decision or making plans to overcome those flaws.

I also think that if you can’t convince your (presumably rational and intelligent) coworkers that your idea is a good one, then it’s possible that you are wrong. Even if you are the manager/architect/god of everything. If you can’t admit you might be wrong, you have no business being in power. And if you don’t believe your peers are rational and intelligent, it’s time to find a new job.