LATE: The Mythical Man-Month Ch 13 - 15

Reference Information:

Title: The Mythical Man-Month
Author: Fredrick P. Brooks, JR.

Summary:
The first chapter in this set talks about debugging. The author begins with a cleaver story about how anyone can make a program, but not everyone can make a program that works. He then spends most of the rest of the chapter talking about various types of debugging used to make programs work. The next chapter talks about how programs are usually not held up by some huge catastrophe, but by a large amount of minor events. Every day that a machine is down or a key person is sick is another day the project is held up. These days add up and eventually the project is very late. In the final chapter, the author states that programs should not only communicate to machines, but also communicate to humans. The author spends this chapter discussing the importance of documentation and explaining documentation practices.

Discussion:
The first and third chapters held no real new information. Since day one in computer science professors beat it into our heads that debugging and documentation are important. The second chapter, however, was extremely enlightening. It makes sense that projects get delayed one day at a time but until someone tells you that you don't really think about it. The book does a good job of explaining how things can become late.

LATE: The Mythical Man-Month Ch 10 - 12

Reference Information:

Title: The Mythical Man-Month
Author: Fredrick P. Brooks, JR.

Summary:
The first chapter discusses the importance of formal documents as well as some examples of formal documents besides those used for software projects, such as documents for a university department. The next chapter focuses on the idea that change is constant and projects should be made to realize that. The first system built is often unusable and that is fine. It is a learning process and as long as you don't stubbornly try to use the first system, you can make a good second system. The final chapter discusses the tools that programmers use. The author recommends that there be one person who evaluates all tools and presents them to the manager who decides what tools best suit the projects needs. Some tools programmers use are things such as operating systems, languages, utilities, debugging aids.

Discussion:
I found the second chapter to be the most enjoyable of this set. The chapters where the author compiles things into a list like structure of organization are really boring to me. Thus, the first and last chapter were not very fun to read. The information is solid and important but I wish it was presented more like the second chapter.