Design by Committee

I love this video:

http://youtu.be/Wac3aGn5twc

It’s great because it quickly gets down to the essence of what happens when a group of people comes together to pursue a constructive project.

The things that have always worked best when building something new, have always had a strong, narrow vision. One strong person’s idea about the final design. One person’s aesthetic. When a committee gets involved, everyone has their own goals and agenda usually resulting in a mixture of watered down, inconsistent ideas. Without a single clear vision, the necessary compromises made by the group weaken the whole.

Committees do have their place, particularly when dealing with negatives or oversight. If you’re looking to protect things from going out of bounds, but the real substance of those bounds is not quantified then throwing a whole bunch of different brains -- different perspectives -- at the problem works well. A group of people are more likely to catch the range of potential problems than just a single person. In that way, a committee can be proactive, and keep something on track.

Construction, however, needs a single focus. An architect designs a building, a painter produces a masterpiece, and a composer creates a melody that reaches out and touches us. Rarely will you see a small team in sync and productive, but never a committee. It just doesn’t work.

We see this over and over again, everywhere in modern life, but we see it frequently in software. Most committee design software projects fail outright. Most “successful” projects, even if they required man-years to complete, started initially with very small teams. The larger the group, the muddier the code and interfaces. The final version of their “stop sign” in the video is a great example. Just too many different goals, perspectives, and agendas.

Not unexpectedly, because software projects are organic -- they continue to grow long after the initial creators have left -- the later versions get more features but become increasingly more painful to use.

My favorite example of this is always Microsoft Word. As each new generation of programmers “contributes” their vision to that product, it becomes increasingly unstable. It just gets worse. It becomes harder to use and less predictable. I liked Word a few decades ago when it was clean and young, but I’ll do anything to avoid it these days. It has succumbed to a committee mindset.

Software suffers more than other disciples because the projects are always huge, long and the developers jump ship frequently. Design by committee doesn’t have to be a formal process occurring all at once; a string of single developers extending a single product, but not fully refactoring it each time to their own vision will leave behind too many compromises. Too many partial, inconsistent implementations all layered over the same code base.

The reasonable thing to do is for projects to get strong initial leadership, and for all ‘assisting’ programmers to figure out the initial vision first, and then to try very hard to keep their work consistent with that approach. In practice, however, most software programmers are more interested in doing it “their way”, even if their way isn’t the best way for the overall project. We have a culture of strong egos and diverse opinions that when left uncontrolled gradually leads to substandard work, to ugly systems, and to outright failure. Too many chefs continually spoil the broth.