The Mythical Man-Month Ch. 13-15

The Mythical Man-Month
Ch. 13-15
Brooks, Frederick P
Addison-Wesley, 1995

Summary:

Chapter 13 discusses methods for testing, structuring, and debugging software projects. In regards to system structure, the author advocates a top down approach where the components of the system are defined and then broken down during "refinement steps". In regards to debugging and testing, the author believes that components should be debugged separately at first and then integrated one at a time in order to test the system as a whole. The author also advocates writing scaffolding in order to help test the code thoroughly and completely.

Chapter 14 focuses on milestones and how they can be used to keep projects on track. According to the author, milestones should be taken very seriously and missing one could indicate bigger problems in the project. The author suggests that managers should use a PERT chart to help avoid missing milestones. It is also the managers job to encourage communication between team members and to provide disincentives for team members who hold a project back.

Chapter 15 discusses how code can be used not only to communicate with computers but with other programmers as well. In order to communicate ideas effectively through code it must be easy to understand and follow. The author also describes certain items that should always be well documented, including IO formatting, descriptions of algorithms, options, range of input and output, etc. Instead of relying on external forms of documentation, the author suggests writing self documenting code by choosing descriptive variable names, using correct formatting, and including descriptive comments.

Discussion:
This reading is useful because it discusses the need for communication when working in team environments, especially through code. I believe that well written code can save programmers from having to verbally explain their code to everyone that needs to use it. I did think that the author could have spent more time discussing how systems can be designed in order to make testing easier. This reading is useful for managers, designers, and programmers since the reading applies to all three positions.