That's the subtext on the "Meetings" inspirational poster from Despair.com.  What it means to me is that you'll never get a great design out of a committee.  When designing a piece of software, you want to get input from many people but how do you keep from being paralyzed by input.  Worse yet, how do you keep the design from becoming an incoherent mess with so many people making the decisions?  The simple answer is to elicit feedback from a large group but continue to act autonomously.

It is my contention that things of beauty tend to come from a single mind.  At best, they come from a small group.  The flip side of this coin is that the ugliest things also tend to come from this same group.  A large number of contributors tends toward bland and average.  Look at television or movies.  The best shows are often those where the creators are allowed creative license.  The shows that merely average are many times those where the studio plays a large role.  Let's take one of my all-time favorite shows, Babylon 5.  The initial series was brilliant.  The studio stayed out of the way.  Fans responded.  After it was finished, there was a spinoff called Crusade.  This time the studio came in and meddled.  They demanded more action.  They rearranged the order of the episodes.  They changed the dialog.  The show tanked.

How does this apply to designing software?  Should you just shut yourself in your office (or cube) and design?  Not exactly.  What makes the great come from a small group and the mundane come from lots of input is that a small group has a coherent vision.  Large groups have a hard time operating under a shared vision.  Each memberr has a different idea of what the outcome should be.  This usually leads to a poor design.  The features are often implemented in a nonuniform way or are difficult to work together.  Sometimes, to satisfy everyone, nothing is pruned.  Every option and setting is exposed.

The value of a single decision-maker is coherency.  As I state above, this can lead not only to the best designs but also to the worst.  Doing things completely alone is often a prescription for even greater disaster than doing them by committee.  What then is to be done?  It is a necessity to satisfy customer desires.  A "great" product no one wants isn't really great.  The secret is to listen to idea but not to be beholden to them.

Recently we were trying to make some changes to a shared test shell.  The major changes were fairly noncontroversial.  The small details, however, became a serious sticking point.  People couldn't agree on the exact semantics.  Each person had a preference.  Most were equally valid but no one idea was coming out on top.  Eventually I called for a close to the debate and told the person responsible to just go with whatever convention he deemed best.  This settled the issue and people are (apparently) satisfied with the results.

Too often we get stuck into a binary mindset.  Either we take feedback and treat it as gospel or we ignore feedback altogether--because we know best.  Instead, we need to mix the two. 

My advice when designing something is to have an individual or a small group with a shared idea drive the design.  This ensures a coherent interface and gives a greater chance that the solution will be elegant.  To avoid the trap of irrelevance, this group should solicit feedback from a wide variety of sources.  They must listen to ideas, but be willing to reject them.