Design By Committee

  • AntiPattern Name: Design by Committee
  • Also Known As: Gold Plating, Standards Disease, Make Everybody Happy, Political Party
  • Most Frequent Scale: Global
  • Refactored Solution Name: Meeting Facilitation
  • Refactored Solution Type: Process
  • Root Causes: Pride, Avarice
  • Unbalanced Forces: Management of Functionality, Complexity, and Resources
  • Anecdotal Evidence:

    "A camel is a horse designed by a committee."

    "Too many cooks spoil the broth."

Background

Object orientation is often described as a two-generation technology. Data-centric object analysis is characteristic of the first generation, and design patterns are characteristic of the second.

The first generation espoused a philosophy that "objects are things you can touch." A consequence of this is that virtually all designs are uniquely vertical. In the first generation, people believed a number of assumptions that were unsubstantiated by practice.

One of these was that project teams should be egalitarian; in other words, that everyone should have an equal say and that decisions are democratic. This leads to Design by Committee. Given that only a small number of object developers can define good abstractions, the majority rule invariably leads to a diffusion of abstraction and excess complexity.

General Form

A complex software design is the product of a committee process. It has so many features and variations that it is infeasible for any group of developers to realize the specifications in a reasonable time frame.

Even if the designs were possible, it would not be possible to test the full design due to excessive complexity, ambiguities, overconstraint, and other specification defects. The design would lack conceptual clarity because so many people contributed to it and extended it during its creation.

Symptoms And Consequences

  • The design documentation is overly complex, unreadable, incoherent, or is excessively defective.
  • The design documentation is voluminous (hundreds or thousands of pages).
  • Convergence and stability are missing from the requirements and the design.
  • The committee meetings resemble bull sessions during which substantive issues are rarely discussed and progress is painstakingly slow. People talk and work serially; that is, there is a single thread of discussion, and most people are unproductive most of the time.
  • The environment is politically changed, and few decisions and actions can be undertaken outside of the meeting; and the meeting process precludes reaching timely decisions.
  • There is no prioritization of the design features, and no ready answer to the questions: Which features are essential? Which features will be implemented in the initial delivery?
  • Architects and developers have conflicting interpretations of the design.
  • Design development becomes significantly over-budget and overdue.
  • It becomes necessary to employ specialists to interpret, develop, and manage the specifications. In other words, dealing with each specification that was designed by committee becomes a full-time job.

Typical Causes

  • No designated project architect.
  • A degenerate or ineffective software process.
  • Bad meeting processes, marked by lack of facilitation or ineffective facilitation. The meetings are bull sessions; the loudest people win and the level of discourse is the lowest common denominator of sophistication.
  • Gold plating—that is, features are added to the specification based on proprietary interests. This can happen for many reasons: marketability, the existence of proprietary technologies already containing these features, or speculative placement of features in the specification for potential future work.
  • The attempt to make everybody happy, to satisfy all of the committee participants by incorporating their ideas. Unfortunately, it's impossible to accept every idea and still manage complexity.
  • Design and editing is attempted during meetings with more than five people.
  • Explicit priorities and a software-value system are undetermined
  • Concerns are not separated, and reference models are not used.

Known Exceptions

There are few exceptions to the Design by Committee AntiPattern, and they occur when the committee is small: approximately 6 to 10 people; more than that and consensus becomes unlikely; fewer than six people and the breadth of understanding and experience become insufficient.

Also, committees should often be tiger teams, a small group of "experts" in a particular problem domain, organized for the duration of the solution for a specific problem or issue.

Refactored Solution

The essence of the solution to Design by Committee is to reform the meeting process. It's fair to say that most people are accustomed to enduring bad meetings, most of the time.

Thus, even simple alterations in the meeting process can yield substantial productivity improvements. With improved productivity, there is an opportunity for enhanced quality and more sophisticated solutions. Typical gains for software optimizations are less than an order of magnitude (2 to 10 times). Meeting productivity gains are much more dramatic, with several orders of magnitude typical (100 times), and we have seen productivity gains over 100,000:1.

First, most meeting rooms do not have a clock on the wall, particularly in hotel facilities. Time awareness is essential to meeting progress. Participants should be coached to manage the time allotted efficiently; participants should start their comments with a "25-words-or-less" summary, and add details only if requested. Posting the meeting goals, an agenda, and a clock where they are visible to all participants can improve meetings dramatically.

Second, in all meetings it's important that group members answer two questions: "Why are we here?" and "What outcomes do we want?" When no meeting plan is prepared, it is particularly important that the group start with these two questions, and then work on generating the desired outcomes.

Another important reform is to assign explicit roles in the software process: owner, facilitator, architect, developers, testers, and domain experts. The owner is the manager responsible for the software development. He or she makes strategic decisions about the overall software process, and invites and organizes the participants.

At the beginning of the meeting, the process owner sets the goals and establishes expectations regarding the handling of the outcomes. For example, the decisions made at the meeting may be regarded simply as advice or be implemented exactly as discussed.

The facilitator is in charge of running the meeting. He or she is responsible for the process; other participants are responsible for technical content. The facilitator turns to the process owner if there are any key decisions to be made regarding the process.

The architect is the senior technical lead for the software project. He or she controls the editing of the architecture documentation, and may be in charge of key, system-level boundaries, such as the subsystem application program interfaces.

Each developer is typically responsible for a single subsystem and unit testing. Testers are responsible for monitoring specification quality and value-added testing such as integration, portability, and stress tests. The domain experts input key requirements to the process, but may not be involved in all aspects of development.

There are three categories of meeting processes: divergent, convergent, and information sharing. In a divergent process, ideas are generated for later utilization. In a convergent process, a selection or decision is made that represents a consensus. Information sharing can involve presentation, teaching, writing, and review.

The number of people involved in each meeting process is managed by the facilitator. Creative processes that require writing, highlighting, or drawing should be limited to breakout teams of five people or fewer.

Groups larger than five are less effective at making progress in creative tasks, although they are successful at reviewing and integrating results after a creative process. Highly productive meetings involve many parallel processes, and frequent iterations of breakout and review groups. Encouraging people to make a paradigm shift between single-threaded discussion and parallel work is a key challenge for the facilitator.

The primary purpose of most meetings is problem solving. A general problem-solving approach begins with a convergent process: The problem is defined and scoped for the group to resolve.

A divergent process is used to identify alternative solutions. Information sharing may be needed to explore the details and consequences of selected alternatives. Finally, a convergent process is used to select among the options.

One highly effective meeting process is called Spitwads It's a general-purpose procedure that we have used on many occasions with excellent results.

  1. Ask the question. The facilitator poses a question for the group to brainstorm. The question is written down on a viewgraph or flipchart) to avoid misunderstandings. The group is asked whether there are any suggested changes to the question before the brainstorming starts. Typical questions are: "What are ways that we can improve the performance of the system?" and "What is the most important requirement that has not been addressed?"
  2. Write silently. The participants write responses on identical slips of paper. Each response is written on a separate piece of paper, and is limited to short phrases.
  3. Toss spitwads. As the participants complete each idea, the facilitator instructs them to wad up the paper and toss it across the room into a receptacle—a cardboard box or a basket works best. This is done basketball style, and the facilitator encourages the participants to have fun with this exercise.
  4. Conduct spitwad roll call. The "spitwads" are distributed randomly back to the participants, who one at a time read the ideas out loud to be recorded on a flipchart. Two flipchart recorders can be used simultaneously to speed up the process. The flipcharts are posted on the wall for all participants to see.
  5. Reach common understanding. The ideas on the flipcharts are numbered. The facilitator then asks the group if there are any ideas that they do not understand. If so, the members of the group are encouraged to offer definitions. If an idea cannot be defined, it is safe to eliminate it.
  6. Eliminate duplicates. The facilitator asks the group to identify any ideas that are duplicates or that should be combined. Participants identify the ideas by number to suggest changes. If there is an objection, the changes are overruled. (This is a common facilitation approach for editing: If there are objections to a proposed change, then the change is not accepted.)
  7. Prioritize. The group is directed to silently select the best ideas on the list by number. They can pick more than one. The facilitator walks through the list tabulating votes (raised hands, no discussion).
  8. Discuss. The exercise is complete. The group discusses the highest-priority selections and suggests what the follow-up actions will be.

Variations

The Railroad (also known as Rubber Stamp) AntiPattern is a variation of Design by Committee, whereby a political coalition dominates the process and forces the adoption of designs with serious defects. The Railroad is often motivated by mutual business interests of many members of the committee. By adopting incomplete and defective specifications, details of the technology can be hidden effectively in the software.

In this way, software from a coalition developer becomes the de facto standard, as opposed to the written specifications. Some developers outside the coalition will even attempt to implement the "misfeatures," resulting in wasted time and money.

Example

Two classic examples of Design by Committee come from the domain of software standardization: the Structured Query Language (SQL) and Common Object Request Broker Architecture (CORBA).

Sql

The Structured Query Language (SQL) became an international standard in 1989. The original, SQL89, was a small document—115 pages—that represented an efficient, minimal design for the technology Virtually all relational database products implemented the full specification.

In 1992, the second version of SQL was standardized with significant extensions that resulted in a 580-page document. The SQL92 specification was implemented with a unique dialect in every product; few products implemented the entire specification. The next version of SQL, called SQL3, may well be thousands of pages in length.

The standards committee responsible for the design is adding a smorgasbord of new features that extend the concept well beyond the original intent. Some of the new features include object-orientation extensions, geospatial extensions, and temporal-logic extensions.

It's unlikely that any product will ever fully implement SQL3, nor is it likely that any two products will implement the same subset in a portable manner. In this classic Design by Committee, the SQL standard has become a dumping ground for advanced database features.

An interesting solution to the problems of SQL convergence is presented by the technologies: Open Database Connectivity (ODBC) and Java Database Connectivity (JDBC). Each defined a standard application program interface for database access based on dynamic queries, query statements that are submitted and parsed at run time.

Because ODBC and JDBC define the query interface and query language for the clients, they provide isolation from product-specific database features. Clients can access multiple database products transparently. ODBC became an industry standard through the SQL Access Group (SAG), a software industry consortium.

Microsoft developed the ODBC specification independently of SAG, and then proposed it to the group. The specification was adopted rapidly by SAG and became a de facto industry standard. Vendors that promote proprietary solutions have had difficulty replacing this highly effective technology, which is universally supported by database vendors and database tool developers.

Corba

The Common Object Request Broker Architecture (CORBA) standard was adopted by the industry in 1991. The original document—fewer than 200 pages—was easily readable by outsiders to the Object Management Group (OMG) process. In 1995, a revised CORBA2 specification released, with significant upgrades and extensions, including C++ and Smalltalk mappings, the Interface Repository, and the Internet Inter-ORB Protocol (IIOP).

The C++ mapping in CORBA2, in particular, contained complex details that could not be implemented consistently by Object Request Broker (ORB) vendors, some of whom changed the APIs generated by their IDL/C++ compilers repeatedly. The Basic Object Adapter (BOA) had been substantially revised in CORBA2.

A replacement of this part of CORBA, called the Portable Object Adapter (POA), was adopted in 1997. Since the POA duplicates BOA functionality already in working products, successful vendors may have little motivation to upgrade their products. And because of all this attention on the basic infrastructure, some of the more critical needs of users are allocated lower priority.

An alternative process used by OMG to identify and define technologies for adoption was used by the OMG to produce the CORBAfacilities Architecture. This process was reused by other task forces and end-user enterprises to define their architectures and road maps. The authors called this the "Lost Architecture Process" because it was undocumented (until now).

The Lost Architecture Process is a facilitated architecture-definition procedure that entails the following steps. It may be adapted to the needs of specific enterprises, by replacing OMG processes with organization-specific processes, such as internal surveys and off-site workshops.

  1. Release a request for information (RFI). The purpose of the RFI is to survey interested parties both inside and outside OMG. Interested parties from any organization are asked to submit their requirements, architectural input, and descriptions of relevant technologies to assist in the planning process.
  2. Review the RFI responses. Any responses received (typically a dozen or fewer) are reviewed by the task force. This completes the survey and data-collection phase of the process. Once the task force has reviewed this input, it becomes the responsibility of the people in the room to define the architecture.

    The RFI process is an important step psychologically, because it transforms an undefined set of stakeholders and implicit requirements into the responsibility of the meeting participants to define the architecture and draw the road map.

  3. Identify candidate services and facilities. The candidate services are listed on flipcharts and posted in the meeting room for participants to review. This listing can begin during the RFI review process, and a brainstorming session can extend these lists with additional facilities. It is important to solicit all ideas, then to cull the list, watching for duplicates and overlapping services.
  4. Launch the initial RFP process. Probably, at least one of the identified services will be an obvious candidate for an RFP release. It is highly likely that some team of vendors is attending the meeting with the goal of adopting a particular technology. This team can break out to work on the initial RFP and start the task force adoption processes. The other services and facilities will be defined during the balance of the process.
  5. Diagram the architecture. A small breakout group organizes the list of services into categories, in the form of a block diagram showing layers of services and horizontal delineations. Obviously, this group needs at least one person skilled in reference model diagramming techniques. This architecture reference diagram is a useful abstraction of the listed services, and will be an important illustration in the architecture document. All services and facilities are listed in the diagram.
  6. Define preliminary service. The group parcels out services to be defined in terms of a number of viewgraph bullets. People meet in small groups or work individually to define the services in this form. The results are reviewed and discussed by the entire task force, during which additions and edits to the bulleted phrases are recommended and discussed.
  7. Write the service definitions. Using the content portion of the RFP template, each of the identified services is written up. Writing assignments are worked on in between meetings. At this point, an architecture document editor (just one person is best) must be appointed to receive the inputs and create a draft document.
  8. Draft the document. The document editor assembles the submitted service definitions and the architecture diagram into a draft document. The editor may add boilerplate descriptions of the overall architecture so that the document can stand on its own.

    A table of services and service categories is also included in the document to summarize and abstract the contents of the service definitions.

  9. Review the process. An updated draft of the architecture document is reviewed at each meeting. Editorial changes are proposed and discussed for the next revision. Any missing sections or service write-ups are assigned to group members for independent work and incorporation by the editor.
  10. Define the road map. The road map is a profile of the architecture that focuses on priority and schedule. Several key criteria establish the priorities and define the schedules. These include industry need for the technology, dependencies between technologies, broadness of technology applicability, and the workload of the task force.

    The road map definition is a critical part of the process that allows member groups to organize resources and plan research relevant to the adoption processes.

  11. Conduct the approval process. After several iterations of the review process, a motion is made to release the architecture and road map as version 1.0. Further revisions can occur after version 1.0 is released; however, the passage of this motion indicates that the task force has reached a consensus on the initial architecture.

Related Solutions, Patterns, and AntiPatterns

Kyle Brown posted a version of the Design by Committee AntiPattern on the Portland Patterns Repository site That pattern uses a different template, which focuses entirely on describing the problematic solution and not upon the refactored solution. In contrast, this book includes a refactored solution with each AntiPattern, noting that Socrates was put to death for exposing society's contradictions without offering any constructive suggestions.

Applicability to Other Viewpoints and Scales

The impact of the Design by Committee AntiPattern on developers is that they are expected to implement a highly complex and ambiguous design, which is a stressful situation. They may find the need to quietly subvert the demands of the committee with more realistic design approaches.

Managers suffer from this AntiPattern through a dramatic increase in project risk caused by the excessive complexity. Correspondingly, the schedule and budget of the project are likely to increase dramatically as the consequences of the design are discovered in the laboratory.

At the system level, it might be reasonable to deliver a system based on a Design by Committee specification, if no variations (multiple configurations) are required and the proposed implementation schedule is extended by 30 percent or more. Most developers can manage only a few variations, in platforms, databases, and feature sets.

Read next