Mythical Man-Month

I just finished reading The Mythical Man-Month. It's interesting, because it was written in the late 60s, and is an analysis of managing large software projects at that time. The title intends to debunk the idea that if it takes one programmer 12 months to do something, it will take two programmers 6 months, and three programmers four months, etc. The man-month, Brooks admits, is still a convenient shorthand for estimating projects, but adding more staff to a project does not mathematically expedite production, and, Brooks argues, adding staff after the schedule has begun to slip will never bring it back the original schedule. The reason, as he demonstrates thoroughly, is that adding manpower adds additional avenues of communication, takes trained people off-task in order to bring new people up to speed, and, most damaging, often calls for re-allocating tasks within the team, which means everyone (new and existing staff) has to reorient themselves. The more often this happens, the greater the amount of work time is spent on non-productive internal communication, and no meaningful advances are made on the original project.

Some of my favorite quotes are:

First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well. (Later, he defines "going well" as "each task will take only as long as it 'ought' to take.")
Second, our estimating techniques fallaciously confuse effort with progress, hiding our assumption that men and months are interchangeable.
...
Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse.

Observe that for the programmer, as for the chef, the urgency of the patron my govern the scheduled completion of the task, but it cannot govern the actual completion.

In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done. Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.
The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer. Delivering the throwaway to customers buys time, but it does so at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down.
Hence, plan to throw one away; you will, anyhow.

I appreciate that so much of what he wrote about is still applicable today, for all kinds of project management, and his insights are valuable. He has some great thoughts about keeping teams productive and management style, and some recent analysis at the end revisiting (and confirming) the original premise of the book.