The Mythical Man-Month, Chapters 13-15

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


Summary
Chapter thirteen discusses how programs should be designed and built, along with using milestones to measure progress and completeness. The most common bug arises from misunderstandings between authors of different components. The outward-facing functions and definitions of each component should be meticulously documented. To ensure quality, the fully-formed specification should be looked-over by outside experts. The author emphasizes the need for top-down design. Top-down design is a processes whereby a broad task definition is made and then subsequently refined in many steps that each focus on a smaller and smaller portion of the design. The author believes that this system was one of the most important advances in software engineering. Structured programming is important for creating program flows that are easy to follow, including removing most of the uses for GOTO statements. Interactive debugging, which is provided by most modern languages, enables the developers to find and fix problems rapidly. Plenty of code should be written for testing the system, which the author terms scaffolding. Each component of the system should be tightly controlled by one person who must approve any changes. Along with this, only one component should be added to the system at a time.


Chapter fourteen, entitled Hatching a Catastrophe, discusses milestones. Milestones are a result of having a schedule. They must be concrete and very specific. Milestones can indicate a transition between the phases of planning, coding, and debugging. Each slip of the schedule must be treated as a serious incident. The author recommends using a PERT chart to maintain the schedule. A PERT chart is created by creating three estimates for each event and combining them with three probabilities of reaching completion dates. Simply preparing the PERT chart gives a large benefit to the project.


Chapter fifteen, The Other Face, introduces various techniques for documenting code. A program is communicating both with a machine and also with other people. Therefore, it must be documented in plain language for them to better understand. Various things that need to be documented are purpose, environment, domain and range, functions/algorithms, I/O formats, operating instructions, options, running time, and accuracy and checking. Programs must be supplied with test cases so that the user can be sure that it is functioning properly. For future modification of the program, a flow chart should be provided that explains how the program works. However, the flow chart should only be a high-level overview, too much detail only interferes with understanding. The author recommends using self-documenting code where possible. This includes moving all documentation into the code files themselves. The variable names and formatting of the code can help as much as additional documentation.


Opinion
Most of what was presented has entered into mainstream programming thought since the book was published. We were taught about self-documenting code in our courses in school. The top-level design process appears to be the most natural way to attack large programs, so that they can be broken down into more manageable chunks.

An example PERT chart