The Mythical Man-Month, Chapters 1-3

Reference Information
The Mythical Man-Month
Brooks, Frederick P., Jr.
Addison-Wesley, 1995


Summary
The first three chapters introduce the key concept of the book and a potential team structure that would be best suited for team projects. The first chapter, entitled The Tar Pit, explains the difference between a program and a finished programming systems project. According to the author, there are four different types of programs. A basic program simply accomplishes a specific task. A programming product must be generalized, have extensive testing, and be thoroughly documented. A programming system consists of many programs or systems acting in unison. A programming systems product is a merger of the previous two types. The author associates a cost to each of these: base effort for program, 3x effort for both product and system, and 9x the effort for a systems product. Next, the pros and cons of programming are listed to emphasize the joy and work that programming brings.


Chapter 2, which has the same title as the book, frames the problem that is often faced in software projects and attempts to explain why throwing more people at project does not help it finish earlier. The author lists these as the reason why software projects fail:

• Estimations are typically poor
• Effort does not equal progress
• Since there is little confidence in the estimates, assertiveness is lacking
• Progress is poorly monitored
• When things fall behind, the typical solution is to add more manpower

In addition, the author claims that cost is a function of men and machines committed to a project, but progress is not. Men and month costs are only equivalent if the tasks are highly parallel with little communication between the individuals. Communication itself should be added to the work done. Communication also encompasses training, which is the main hurdle to adding new people to a project since it takes productive people away from their work while they instruct. The author recommends a schedule of:

• 1/3 planning
• 1/6 coding
• 1/4 component and early system testing
• 1/4 system testing

The chapter is concluded with the idea that adding new programmers to a late project costs the project time and ultimately makes the project even later.

Chapter 3 introduces a team structure that was proposed by Harlan Mills. The team is made up of these specialists:

• The surgeon
• The copilot
• The administrator
• The editor
• Secretaries
• The program clerk
• The toolsmith
• The tester
• The language lawyer

Opinion

Chapter 2 in particular presented some interesting concepts which hopefully will be expanded upon later in the book. The team proposed in Chapter 3 seems quite ludicrous, almost like a super heroes gathering. The team is so large and unwieldy, with so much support staff and so few actual "front-line" people, that it would be surprising if any work actually got done. It also seems like a complete waist of resources since these specialists certainly would not come cheap. Also, the ideas presented here completely contradict those from extreme programming.

Specialists, Assemble!