by Frederick P. Brooks, Jr.
In Chapter 13 of The Mythical Man-Month, Brooks Jr. talks about building a program to work; putting all the little pieces together, testing and debugging, and integrating into the larger system. The first important step is to make sure your design and specification is "bug-proof." Everything major in the project should be defined clearly, and should be looked at by a third party to find errors and gaps that might be there. Some of the hardest errors to find are those when programmers of interacting systems assume different things about the code, whether it be the structure of the class or the way a message is formed. Top-down design is also very important; this procedure starts with high-level abstractions and sketches, and continues to refine the design down to the level needed for the programmers and implementers. Lastly, debugging is really important during the programming process. Whether it's done on-machine, in a batch setting, through memory dumps or snapshots, or interactively, careful attention should be made to debug as you go. When building a larger system, make sure that the smaller components have been debugged individually so we can rule out component-specific bugs.
In Chapter 14, he addresses the issue of schedule slippage; why projects can slowly get behind schedule, and tools to keep this from happening. The most important thing of a programming project is it's schedule. In that schedule, we have a list of milestones, with concrete dates. These milestones must be completely specified so not a single person can argue about what it means, and have measurable events and a specific date they must done by. The more specific it is, the harder it is to lie and say that it's finished. PERT charts are also important because they allow you to lay out the schedule, with probabilities that events will be finished by the due date. It will also give you a concrete diagram of the dependencies between different parts of the system. Another problem is "the rug," meaning that whenever a small team slips behind, it won't always come to the attention of the main boss. Even though that manager may think they can fix the problem, this should always be told to the boss because they can use contingency plans to fix the issues. Lastly, the PERT chart should be used to make reviews throughout the project and find issues of schedule slippage as soon as they happen.
In Chapter 15, Brooks Jr. emphasizes the importance of good documentation, and explains the most important documentation needed for a software product. First of all, the user needs an easy to read description of the program, including the purpose of the software, what kind of input it takes, the format of the output, different options the user has, exactly how to do those options, and how to make sure the program is working correctly. The user also needs some documentation that helps them believe the program works correctly, including examples that they can run, test cases, etc, that show different inputs and their corresponding outputs. When something goes wrong with the program, the user needs a description on how to modify and fix the issue. Usually, full detail for the user is required, which could include a flow chart, descriptions of the algorithm used, or an explanation of the file structure of the program. He spends the rest of the chapter talking about self-documenting programs, which really just means "comments." These comments in the code allow for the programmer to analyze the code and also see the documentation at the same time, not having to worry about looking back and forth between code and another document.
Again, the stuff that Brooks has to say makes sense, but is kind of obsolete in our day. In his time, this information on high-level languages, interactive debuggers, and comments inline in source code must have seemed radical but extremely useful. It is interesting to read this book as a history lesson, because it accurately describes the techniques used before, and the modern-day solutions to those problems. Comments in source code definitely help, and having someone check over your design to check for gaps before implementing is definitely a good idea. I think the most important thing was the "top-down design" approach. It definitely helps to get a good picture of exactly what you want your code to do before bothering yourself with possible implementation strategies and how you will test the code.
No comments:
Post a Comment