Design by Committee

I have recently been helping a friend build some stuff – a special kind of website, really. The reason that I agreed to help them was because I felt that their objectives were sound, that they did not have anyone who could do it right, and that I did it as a favour to my friend.

I have been working on the system for about 3 weeks now, as the sole developer building the things. This friend of mine keeps suggesting ideas that I keep trashing. Yesterday, my friend suggested another idea and after I rejected it, my friend took it up with the team looking for support. In order not to waste time debating the idea, I pulled rank and shut it down.

My friend is confused – software development work is not a democracy.

Design by committee is a term referring to a style of design and its resultant output when a group of entities comes together to produce something (often the design of technological systems or standards), particularly in the presence of poor and incompetent leadership. The defining characteristics of “design by committee” are needless complexity, internal inconsistency, logical flaws, banality, and the lack of a unifying vision.

If you want to develop mediocre stuff – maybe – but if you want to build something good, it is not a democracy. Look at the good software products – they were the brainchild and work of generally one person e.g. Linux. Even today, when Linux is worked on by thousands of contributors, when it comes to policy decisions, Linus calls the shots. Classic examples – monolithic vs microkernel, c vs c++.

The reason for this is simple – when it comes to technical decision, you cannot leave it up to the majority who tend not to know a thing about it – you leave it to the technical expert in charge. Say, when it comes to adding a feature that has the potential to compromise security of the system, you leave the decision to the security guy, not a majority vote.

In addition, when there is only one guy writing the code, you leave it to that guy to make the call. He is responsible for delivering the feature and making sure that it works correctly and safely. Only he knows how much effort and rework might need to be done to cater to that one feature. Only he has any idea what needs to be done to get things to work.

Any software that is designed by committee is going to suck, universally.

Often, when software is designed by a committee, the original motivation, specifications and technical criteria take a backseat and poor choices may be made merely to appease the egos of several individual committee members. Such products and standards end up doing too many things or having parts that fit together poorly (because the entities who produced those parts were unaware of each other’s requirements for a good fit).

A similar thing happened a couple of weeks ago. They wanted a feature that I opposed and after wasting over an hour debating over it, they finally came to the natural conclusion that my way was the right way. I could have told them that right from the start! I am not going to waste more needless hours debating over other features.

I’ve already given my friend notice because I know that I cannot work with these bunch of people. I have zero tolerance for stupidity.

PS: This also explains why the stuff at work, generally sucks and why life sucks in general too.