The Mythical Man Month- Chapters 1-3

One inventory tracking system, coming up

The Mythical Man Month: Frederick Brooks

Summary

This month late reading is looking at the first three chapter of Mythical Man Month: The Tar Pit, The Mythical Man Month, and The Surgical Team.

The Tar Pit serves as an introduction to the book. It starts off by asking why we still see massive development teams if garage sized teams are able to move mountains. The core answer comes down to what is being built: garage teams often focus on a single program, whereas programming armies are often more interesting in systems or products, which have radically different (and more painful) requirements. It then goes into what is enjoyable and what is tar pit like about programming. 

The Mythical Man Month goes into the process of debunking the idea that a project can be quantified in terms of man-months (sort of a unit of wasted life). It states that only if a task is perfectly partition-able (ie its more like a massive group of completely unrelated tasks) can the concept of a man month be well applied. Otherwise it is doomed to miserable failure. 

Finally, the surgical team concept looks at a unique way of forming a team of 10 to increase accountability and decrease lines of communication. It takes inspiration from the concept of a surgical team (as opposed to the concept of near equal distribution in other laboring teams). The team is formed on the concept of having a single person largely responsible for all the work, a second to bounce ideas off of, and a legion of support personnel.

Discussion
1. Why is this paper interesting or significant?
The surgical team concept is an interesting way of dividing up work, with certain nice aspects to it. The mythical man month is basically saying "dont treat man month estimates as pure numbers", which is a valid statement. To an extent, it's kind of like MPG on a car- yes, if you drive 55 on the highway with no stops downhill you'll get 150 mpg.

2. What are the faults of this work?

The surgical team concept ends with one person responsible for writing meaningful code in a team of 10. Maybe 2 if the copilot gets uppity, and kind of 3 with the toolsmith, but not really. I find it hard to believe that that large of a team could be justified for the output of a single individual today. In years past, when they were using punch cards and machine operators (as mentioned in the text), this approach would have made much more sense. But today, with the tool support from modern IDEs and languages, I think that work distribution is unrealistic in its resource underutilization. It also ignores that a lot of programming today is drudge work- effectively connecting lines together.

Also, the man month chapter is based on the idea of having a man month estimate before a project begins. It seems to disregard the factor of individual effectiveness as a means of further debunking the man month concept.

3. What is the possible future work extending from this work?

Legions of research papers. I would be curious to see how a structure similar to surgical teams would work today, but I'm not sure how such a thing could be objectively tested.