The Mythical Man-Month Ch 1 - 3

Reference Information:

Title: The Mythical Man-Month

Author: Frederick P. Brooks
Publisher: Addison-Wesley

Summary:

Chapter 1 - The Tar Pit

In this chapter, the author talks about system programming by referring to it as tar pit. The authors talks about how a small program grows into a big project later becoming a marketable product. He states that the complexities of system programming considerably slows down the process. The author talks about the sheer joy in programming and how it encourages creative thinking. He also mentions that the process of debugging does get pretty boring.

Chapter 2 - The Mythical Man Month

In this chapter, the author addresses various causes for project failures. He mentions that the most common cause is time i.e. inability to meet deadlines. The chapter presents various reasons for why time is mismanaged. By mythical man month he means to differentiate between time in man-hours and productive work-hours. Estimating time in man hours often gives a wrong estimate. Other factors include too much time spent in testing and pressure from the customer. The author finally provides a rule of thumb for properly allocating time for various stages - 1/3 time for planning, 1/6 for coding, 1/4 for testing components and 1/4 time for system testing.

Chapter 3 - The surgical Team

This chapter talks about how to structure the team to increase the effectiveness of the task. He compares an ideal team to a surgical team. Smaller and smarter teams are most efficient but unfortunately, they are not suitable for large projects. A team of reasonable size of 10 can be perfect for such projects. Such teams should be lead by the head surgeon i.e. the lead developer who is responsible for key aspects of design and development. He is assisted by yet another experienced individual. Manager is responsible for administrative work, editor translates the technical jargon used by the development team into documents used by customers, the clerk maintains the records, secretaries provide assistance to these people. A toolsmith creates helpful tools, the tester writes test cases and the language lawyers uses his/her technical acumen and programming language skills for the tricky work.

Discussion:

So far, the books seems pretty interesting, especially because of the way the author puts the information. However, I personally prefer a direct way of stating the facts. I don't mean to be rude, but I prefer the "cut the crap" approach. This is why I liked the Extreme Programming book better. Also, in the rule of thumb, he assigns least amount of time to the coding phase which doesn't make much sense to me. I think design phase should be short, while coding should be done with care and caution.