The Mythical Man-Month, Chapters 10-12

Reference Information
The Mythical Man-Month
Brooks, Frederick P., Jr.
Addison-Wesley, 1995


Summary
Chapter ten, entitled The Documentary Hypothesis, discusses the need for extensive documentation during the development process. Documents that should be generated include the objectives, specifications, schedule, budget, organization chart, space allocations, and estimate prices. These documents collectively answer the questions what, when, how much, where, and who. Writing these documents will help expose inconsistencies in the product. In addition, the documentation facilitates communication and provides a convenient checklist of features. 


Chapter eleven is about the need to write a prototype system whose function is to expose most of the implementation issues that could not be foreseen. The author likens this to how chemical engineers must design and build a smaller pilot plant before building the real thing as a proof of concept. The first system build is rarely usable as a product. Therefore, management must plan to build the product twice, if it wants to deliver a remotely decent product. Another problem that frequently occurs is that the requirements for the software change during the development process. To counteract this, the software should be very modular so that any required changes only affect a small portion of the project. The whole organization must also be able to be flexible and to withstand change. The author gives examples of some companies abolishing all job titles: without a title, everyone has equal responsibility. Change continues even after the delivery of the "final" software. The cost of maintaining software can easily be 40% more than the cost of actually developing it. Since many of the people who maintain the software were not on the original programming team, many additional bugs may be introduced in the maintenance phase. Each defect that is fixed has a large chance of introducing another such defect. Even worse, constant fixing-up and patching will destroy the structure of the original program.


Chapter twelve discusses the need to use tools appropriate for the job. Most tools should be shared by the entire team. If each person on the team uses different tools, it dampers communication and efficiency. Common tools need to be found or created that satisfy the entire team. The author discusses many considerations that were relevant a very long time ago, but are omitted here. He says that it is far better to create too much documentation than to not fully document the software. Using a high-level language is crucial, along with interactive programming.


Opinion
Writing a prototype system and then throwing it away seems like an enormous waist of time, except that I have personal experience in this matter and can say that he is absolutely right. Many times, the first implementation uncovers many design flaws and pushes the software in a new direction.