Comments on Mythical Man-Month: Chapter 1

Analysis of Brooks' bullet points from Mythical Man-Month chapter 1. (note: these will all be interlinear)

Chapter 1. The Tar Pit

1.1 A programming systems product takes about nine times as much effort as the component programs written separately for private use. I estimate that productivity imposes a factor of three; and that designing, integrating, and testing components into a coherent system imposes a factor of three; and that these cost components are essentially independent of each other.

The numbers Brooks chose (3 and 3) are wildly divergent depending on the kind of software system being developed. Is it a big system with large modular parts? Is it a small highly optimized system? Is it a -new- system? I think realistic numbers could be made with a lot of differentiation of what system means and a lot of experimentation. The primary point is that design/integration/testing are a big part of any project. I actually don't know what he means by 'productivity', but I'll grant 'independence'.

1.2 The craft of programming ''gratifies creative longings built deep within us and delights sensibilities we have in common with all men," providing five kinds of joys:

• The joy of making things.
• The joy of making things that are useful to other people.
• The fascination of fashioning puzzle-like objects of interlocking moving parts.
• The joy of always learning, of a nonrepeating task.
• The delight of working in a medium so tractable- pure thought-stuff-which nevertheless exists, moves, and works in a way that word-objects do not.

These five points are not particularly independent (1 and 2 are paradoxically not independent, and I consider 1 and 3 identical in this context of programming/systems engineering, because that is what we are making. As to 'non-repeating', the unwritten implication is the avoidance of boredom. We (programmers) will spend -hours- working on a for-all-time general solution with a one-button-press initiation to avoid having to do a repetitive keyboard operation over and over (that could easily have taken less time than the general solution). In fact, there is (read: 'I have') a visceral reaction to when others do something many times, when it is so obvious that one could do it once.

These points are really just an expression of the general motivating psychology for programmers. It is a good explanation for all the work put into 'open-source' and 'free-ware' ('see what I can do').

1.3 Likewise the craft has special woes inherent in it.

• Adjusting to the requirement of perfection is the hardest part of learning to program.

This is a bit like saying 'math takes getting used to'. Which is not to say that I disagree, it's just speaking to an audience of programming outsiders, which I'd expect is not the primary readership of this book.

• Others set one's objectives and one must depend upon things (especially programs) one cannot control; the authority is not equal to the responsibility.

I think this is simply a statement of the manager/worker/tool situation (managers ask workers to get things done, the worker/programmer attempts to do that using tools, and some of those tools may be created by others outside of one's control. I'm not totally sure about the independence of authority and responsibility set forth here. Again, it's philosophy, other views of the same situations are equally valid.

This sounds worse than it is: actual authority comes from momentum of accomplishment.

This qualification is still unclear.

• With any creativity come dreary hours of painstaking labor; programming is no exception.

True of any skill: painting, storytelling, baseball. I think he's trying to emphasize that programming, which many people are plain unfamiliar with, -is- a skill.

• The programming project converges more slowly the nearer one gets to the end, whereas one expects it to converge faster as one approaches the end.

Could be cynical, fatigue at the end making things harder than expected. But also, many design situations create a tree of resolutions needed: to resolve problem X, a number of subproblems need to be resolved, and each one of those subproblems their own. So the number of problems grows exponentially, but labor only achieves at a linear rate.

• One's product is always threatened with obsolescence before completion. The real tiger is never a match for the paper one, unless real use is wanted.

This sounds like 'whatever you make will be out of date before you get to market'. I'm sure that is a worry of any designer, and comes true all the time but it is still a philosophical statement. For example the opposite is similarly supportable; there are many products, badly designed, poorly implemented, and late (from the initial idea) that have grown and taken over market share despite those failings (Windows is the most obvious example). 

This chapter is really general motivation and psychology rather than anything much experimentally testable. It mostly rings true for me, and I highly suspect for most programmer types. 
 

Note: by 'philosophical' I think I mean 'a cogent thing, but it's opposite, and orthogonal versions are equally supportable'.