Design By Committee

Problem: Given a political environment in which no one person has enough clout to present a design for a system and get it approved, how do you get a design done?

Forces: Often, a problem can be clearly identified for which no existing solution fits well. For instance, the DOD figured out in the mid-late '70s that the existing programming languages that were being used for big military projects just didn't cut it. FORTRAN, JOVIAL and COBOL were not going to allow programmers to write the programs necessary to build things like SDI -- they didn't provide large-scale programming support, encapsulation, or a host of other things that language designers had decided that were needed. However, no one had the force of personality or knowledge to drive through a single, consistent solution.

There was no AlanKay or GraceHopper to provide a vision. So they:

Solution: Put together a big committee to solve the problem. Let them battle it out amongst themselves and finally take whatever comes out the end.

Discussion: The problem with DesignByCommittee is that everyone on the committee has their own vision of the final product. They each fight to get their $0.02 added in to the final version. Since there is no unifying vision, what results is a mish-mash of features in which everybody gets their share put in. By the way, this story relates how the AdaLanguage came about.

: For the record: Ada was designed by Jean Ichbiah, who sometimes vetoed committed decisions that were 12-to-1 against him, see http://www.adapower.com/index.php?Command=Class&ClassID=Advocacy&CID=39 (NanningBuitenhuis?).

--KyleBrown inspired by JimCoplien -- who should probably add his own comments and back references to his organizational patterns.

It should pointed out that some think Ada is/was a fairly good programming language for its day for certain niches. Thus, if it was "designed by committee", then not much can be concluded from that other than being from a committee makes a language neither super popular or a super-failure any more than any other design approach. Many single-man languages have also failed. Only a few bubble to the top with regard to popularity or having a strong fan-base. However, it could be argued that it is more economical for an individual to fail than a group of people to fail. But so far DBC seems to be more successful statistically than single-man jobs such to offset the multi-person time-waste disadvantage. COBOL, ADA, and FORTRAN are committee or at least semi-committee languages that were popular or at least has a decent niche. In short, I see no evidence that DBC is worse than the alternatives, but rather just offers a different set of trade-offs. --top

One of the motivations for developing Ada was that existing languages had standardization problems: Every vendor provides "extensions" to the language to make their product more attractive. Ada has no optional extensions. To call your product "Ada" it must conform to the Ada standard -- no more and no less. (Still, the process was done by committee, which caused problems.) Insight into the way Ada was developed can be found at http://www.adapower.com/lab/adafaq/8.html

At a team building exercise, we were divided up into groups of 4. Each group was given a list of such things as a compass, an extra air tank, a mirror, a rope, etc. We were then asked to pretend that we crash-landed on the surface of the moon some distance from a lunar base. Each of us rated the items, producing a rating listing the items in order of importance to our survival.

We repeated the exercise, but this time each group made one rating, arrived at by consensus.

The moderator read off the official NASA rating, which we compared to our individual and group ratings. The individual ratings had a greater variance from the NASA ratings than the group ratings, which were very close to NASA's.

The "takeaway" from the exercise was meant to be, "Groups made better decisions than individuals."

I prefer this conclusion: "NASA also makes decisions by committee."

-- WayneConrad

I have seen that exercise done comparing individuals against small groups, rather than small groups against big groups. The official conclusion was more persuasive in that the individuals would themselves agree that the group process had done better. Arguably there is a law of diminishing returns, and most of the benefit comes from having just 2 people in the group. (See also PairProgramming.) -- DaveHarris

The limp wristed part of that exercise is that the results can't be tested -- you have no clue whose choices were more likely to actually promote survival.

I have always thought that the team determines if a design is good or not. I have worked on projects where two or three folks couldn't get anything done because we just didn't have the knowhow to put it together. I have worked on projects where we had eight people, all contributing their part to a network design that would never have happened without all eight of those people. The right team can mesh together and get fantastic things to happen. The wrong team can be composed of two or even one and still not get a durn thing accomplished. As the saying goes, "been there, done that too." -- MartySchrader

I too did this same exercise but the context brought a different conclusion: We had several groups. Individuals did it for themselves first and then carried on to advocate their opinion to the rest of their group. Once consensus had been reached, results showed that individuals in a group performed better individually than their group did. The apparent reason was that individuals with natural leadership and strong personalities influenced the group and diverged from established facts in order to meet consensus. The groups results were therefore much worse than the sum of all individual results.

-- PatPitou

Note: Should this page really be labeled CategoryAntiPattern or CategoryArchitectureAntiPattern? Have we not had enough decent discussion here to avoid the use of such pejorative labels?

FWIW, the MythicalManMonth has a list of things designed by one or two individuals (C, Lisp, Unix were on that list), and a list of things that were designed by committee (MSDOS, COBOL were the only two I could remember) and pointed out that the ones that inspired the most passion were those designed by individuals. I can't remember what Brooks said about the design-by-committee products, though. I thought it was an interesting point.

On the other hand, HaskellLanguage was designed by committee, and it's a fantastic language--although others have pointed out that their goal was to consolidate various features from different mostlys-functional languages to create a single purely-functional language.

CategoryPlanning