How decisions are being made in your software development cycle ?

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

It's going to depend on the size of the software team, the sensitivity of the team members, and the maturity of the codebase.

My last project had about 8 team members working in the code at one time, so each task was very finely-grained, each person only affected the small amount of code they were working on, and we had constant code reviews to make sure our changes "fit" with the overall scheme of the project.

My current project (at a new company) is an application that I wrote from the ground up, and no one is using it yet, so I get to be the dictator and decide exactly how things will look. I can make widespread changes to the code, change design patterns at will, and rename and refactor ad nauseum. And until someone else has to get into the code, it takes a lot of self-control to make sure the code will make sense to an outsider. But my hope is that when I'm done, anyone else would be able to jump right in and take over. (Otherwise I'll be maintaining this code forever.)

Answer 2

Worst case, it's sort of anarchy.

In the planning stage of a big project, we sit down with our business analysts to have some Q&A sessions, write up drafts of specifications, and go over specifics of the business needs with subject matter experts. Our team then draws up drafts of design documentation and process flows.

At some point thereafter, all hell breaks loose. The business sees an initial release and suddenly realizes either it didn't clarify what it was asking for, or we didn't clarify what they were asking for, or they didn't know what they were asking for in the first place. Time which should be spent by testers testing is instead spent by developers refactoring, sloppily.

What began as a rough but perhaps relatively elegant solution becomes a load of commented-out code with weird and precarious workarounds and shims applied which challenges everyone's ability to keep from having their own stack overflow of mental notes about what workaround applies under what circumstances to which code.

Time gets wasted, people get stressed, and inevitably more issues are found in testing which must be hammered out. Eventually it can become like something out of Looney Tunes, where a hodgepodge of kitchen utensils, boat oars, people and ocean liners are all stacked and balanced precariously on top of each other (kind of like that weird artist guy who spends his time balancing rocks on top of each other).

Regarding your friend's commentary, that style of leadership is fine in my mind so long as that person is open to discussion with the team. A manager is a manager in part because they manage well (hopefully), if they also code well that's a bonus, but if not they need to be receptive to suggestions by people on their team who are more savvy than they are. Failing that, there's always the fallback position which could be quoted as, "I get paid the same whether I work smart or stupid".

Answer 3

Somebody has to make the final decision. Sometimes (often times) everybody on the team will not agree on something. A good team will have a "buck stops here" person for decisions that have no consensus or are lingering on. Many times I am called upon to be that person. I delegate much of the decision making to team leaders that I trust, but from time to time, piers cannot agree on a direction. I have set the architectural guidance for the company and enforce it. I use input from each team member, that guidance and my judgment to break stalemates. I would not say it is autocratic, but neither is it a complete democracy.

Answer 4

Team decisions rarely provide for the best results in a timely manner. There are usually many ways to solve a problem - performance, quality, maintainability, etc. come in to play to reduce the potential solutions and in the best environments a lead with the most experience and knowledge makes the final decisions (hopefully after gathering input from the team). So, I agree that there should be a person to make the decision and take the responsibility for the outcome - hopefully you're in an environment where the decision maker is held accountable and that the lead is selected based on skill and ability - otherwise, the future will be bleak and painful...at best

Answer 5

Our team is very small: 3 developers in one office, and the owner in the office next door. But even still, I'd say most decisions are discussed among the whole team and ultimately the big ones are decided on by the owner. It works out well. But I think it makes sense to adjust your decision making process depending on the size of your team and how critical to business the decisions are. In most ways, decisions are simply easier with small teams.

Answer 6

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.