Reference:
The Mythical Man Month
Frederick P. Brooks, Jr.
1995 Addison-Wesley
Summary:
Ch. 13 - A fair portion of bugs can be eliminated through the correct implementation of a design. A top-down design can reduce the temptation to apply a cosmetic fix to a faulty design instead of scrapping it and starting anew. Additionally, the control structures of a program need to be seen as such, and not as individual branch statements. Methods for debugging components has evolved over the years. Debugging the entire system goes faster when debugged components and test scaffolding are used.
Ch. 14 - Enough little delays in the production of a system can lead to big problems. Concrete milestones provide a way to track real progress and determine how that progress relates to the schedule. Bosses must know when to let a manager handle an issue and when to become personally involved. An accurate PERT chart can help the boss determine which action to take.
Ch. 15 - Documentation is a key component of system design. There needs to be documentation for the casual user of a system, the user who depends on a system, and the user who modifies a system. A flow chart can act as an effective representation of program structure, but should not exceed one page in length. An effective method in improving program documentation is to merge the program and the documentation together. Symbolic names, labels, and statements should convey as much information as possible to the reader. The formatting of code can improve readability, and comments in the code can be used as a vehicle for better documentation.
Discussion:
Ch. 13 - Debugging is one of the most important parts of programming a system, yet it is one of the most difficult to perfect. There are so many things that can go wrong in a system, and any number of tests will not be able to prove the absence of bugs. Indeed, all testing can do is prove the presence of bugs, so we must do the best we can to ensure the system has high reliability.
Ch. 14 - Now that I think about it, little delays do have a tendency to add up quickly. It is truly better to have 'hustle' and perform better than necessary, so that when a small delay does occur it has little effect on the production schedule.
Ch. 15 - Proper documentation is vital to the programmer. Code that is poorly documented will often make sense to the coder while it is being written, yet seem like a foreign language if the same coder opens it up two weeks later to do some editing. The disconnect is even greater when another programmer has to perform maintenance on poorly documented code. I remember a story when one such programmer found a comment that simply read "RIP LVB." This programmer had no idea what this meant, so spent much time and effort in tracking down the original author of the code to see if the comment contained important information. It turned out that the author was a classical music buff, and had happened to write that particular bloc of code on the anniversary of Beethoven's death. In short, an unrelated and unimportant comment resulted in a significant amount of wasted time.
