There is an old saw about too many cooks spoiling the broth.  This statement roughly describes the design by committee anti-pattern.  While two heads may be better than one for most problems, there is a diminishing return as we add more “heads” to the mix.  At its worst, we end up with a design by committee situation.

Defining the Design By Committee Anti-Pattern

The comments on the definition at the WhatIs.com site provides some excellent food for thought on this anti-pattern. [Click Here to See The Page]

“Design by committee is a term sometimes used to describe a design that is flawed because too many people provided input. The phrase implies a lack of a coherent vision and, perhaps as a result, a failure to successfully solve the problems the design was intended to solve.

We cover a few different reasons why this situation is an anti-pattern.  However, the essential problem with this approach is the lack of a coherent vision.  Think of a tug-of-war.  When everyone pulls the same way, you will gain strength with numbers.  On the other hand, the more people that pull in different directions, the harder it will be to win the match.

Velocity

The first concern often mentioned with design by committee is the speed of making decisions.  A larger team requires more time for everyone to voice their opinion and gather vote results.  A small group will always have the ability to be more agile.  The lower number allows everyone to be fully invested in the decision, make it, and then move to implement.

Diffusion of Expertise

In my mind, the most critical weakness of this approach is what I call the diffusion of expertise.  If the group provides solutions that are an average of the intelligence of the members, then some people are dragging down that number.  In a practical sense, the group may water down its expertise by finding ways to compromise on decisions.  This can arise when the less popular choice (or opinion of a singular expert) is ignored or watered down in a desire to play to the politics of the group.  Instead of driving to get it right, there is a drive to get an acceptable solution.  Once that situation arises, the result will be less than ideal.

Rob Broadhead

Rob is a founder of, and frequent contributor to, Develpreneur. This includes the Building Better Developers podcast. He is also a lifetime learner as a developer, designer, and manager of software solutions. Rob is the founder of RB Consulting and has managed to author a book about his family experiences and a few about becoming a better developer. In his free time, he stays busy raising five children (although they have grown into adults). When he has a chance to breathe, he is on the ice playing hockey to relax or working on his ballroom dance skills.

Leave a Reply