In the sixth essay of The Mythical Man-Month, titled Passing the Word, Brooks tackles one of the largest problems any large project will have: communicating the architecture. Whether you have defined the architecture upfront or just as it is needed, passing the word is critical to ensuring everyone stays on the same page and what gets built works and is what is wanted. This essay provided Brooks’ take on how to ensure that a large number of people hear, understand and implement the architects’ decisions. He describes seven inter-locking techniques for passing the word; they are:
- Written specifications. Many developers value documentation on the same level as reality TV shows; however, as projects and products are scaled past one or two co-located teams documentation becomes a valuable tool. Written specifications define limits, appearance, UX and interfaces. In essence, the written specification is the primary output of the architect that provides everyone with the boundaries of the product and how the user will interact with the product. What the written spec, the product of the architects, doesn’t define how the guts of the product will work which is the purview of the developers. Written specifications do not have to relate to large paper manuals; techniques like WIKI’s have been used to capture and transmit specifications and to solicit interaction.
- Formal definitions. Words are great, but imprecise. Even when everyone involved in an effort shares the same first language (which is less and less true as the metaphorical world shrinks). Formal languages and modeling techniques can be used to document the specification and to capture exceptions and explanations. Alternately, simulators and prototypes are mechanisms that can be used to capture and document the specifications.
The problem with having two definitions of the same idea is what happens when they disagree. Brooks points out that the answer is to never have two communication methods. Rather he points out you need a tool to break the tie if a disagreement occurs. Either have one method of communicating the spec or have three (think odd numbers).
- Direct incorporation. Direct incorporation builds a structure or framework for the product that cannot be changed by the implementer. For example, a set of predefined objects or classes. Deviations and changes, when needed, require renaming and recompiling modules and interfaces. I view this as more of a control mechanism; however, the original structure acts as baseline to communicate the architectural vision.
- Conferences and courts. This category can be described at a high level in one word – meetings. Brooks suggests two types of meetings to control and communicate change. The first is the conference. A conference is a group meeting held on a periodic basis (weekly or monthly) that includes all architects and representatives from the hardware and software developers. Changes and refinements are reviewed and decisions are made. Consensus drives decisions; however, if consensus cannot be achieved the lead architect decides (appeals to overall project leader are allowed). This type of meeting might be recognized as a type of architectural change control board (CCB). The second type of meeting is the “court.” The court is more of a formal meeting of the architects, representatives of the implementers, management, marketing (if relevant) and other stakeholders to make decisions about any nagging issues on how the architectural specification is to be implemented. Courts are typically held annually or semi-annually.
- Multiple implementations. One possible solution to the issue of discrepancies between the specifications and what is implemented is to support multiple implementations. Alternate solutions can move forward and be evaluated. While sometimes possible, in general this solution can generate a significant drain on people and resources.
- The telephone log. Questions to the architects come up as implementers interact with the specification. In this technique you capture all questions and answers and publish them so everyone can benefit from the conversations. Wikis make a great tool for capturing and disseminating Q&A content.
- The product test. The independent test is a tool to identify discrepancies between the specification and the implementation. Some form of independence, whether as an independent test group or through test driven development, is needed to ensure a consistent translation of the vision into a product. Remember that the final arbiter is the customer/user and their product test will be merciless.
Communication is the single most prevalent problem any large group effort will encounter. In Passing the Word, Brooks provides seven possible mechanisms to ensure that everyone hears the same story and has the chance to develop a clear and consistent understanding of that story.
Do you have other solutions that you can suggest? Please share?
Previous installments of the Re-read of The Mythical Man-Month