The Mythical Man-Month Ch 13-15

Reference Information

Title: The Mythical Man-Month

Author: Frederick P. Brooks

Publisher: Addison-Wesley

Summary
Chapter 12 discussed how the parts of a program fit into the whole. It mostly focused on eliminating bugs. It is suggested that to reduce bugs in a program, the definition should be bug-proofed, the specifications should be tested by an outside testing group, a top-down design should be used whereby there are refinement steps to breakdown large steps of the solution into smaller modules, and structured programming should be used. The cycle of debugging procedures was discussed, going from on-machine debugging with carefully designed debugging procedures to having test cases that are often not carefully planned out but can be run multiple times quickly. The hardest part of building is the system test, which should use debugged components, programs and data built for debugging purposes, someone to control the changes, incremental component adding, and quantized updates.

An example of top-down design. In this case, for writing an introduction. However, the idea can be applied to desigining programs. Source: leo.stcloudstate.edu

Chapter 14 discussed to incident of shifting schedules. There should be a schedule that contains a list of milestones, each with a concrete event and date. to make it easier to stick to the schedule. PERT charts are helpful for keeping track of progress. The fact that the manager is not inclined to let his boss know about the gradual slipping of the schedule was also discussed, and the book suggests that the boss must change his behavior to encourage the managers to keep him updated.

Chapter 15 discussed the user view of the program, and the ways different project documentations must be presented depending on the situation. The book emphasizes that flow charts are only helpful if they are one page, and that they usually are not done until afterward. Finally, self-documenting programs were discussed, whereby the program's documentation occurs within the code itself by use of commenting and proper naming of variables.

Discussion
I especially liked that the book suggested that showing someone how a job is done is much more successful than just telling them how to do it. I also prefer the self-documenting approach to writing tons of unhelpful documentation to accompany the code. I think both of these ideas should be used in future work, to make code easier to read and modify and to show users how to use the program in a proper way. I did, however, think the discussion about managers telling the boss about schedule slips to be a little unrealistic, since many bosses would not be very amenable to hearing that.