I've been reading Frederick P. Brooks' The Mythical Man-Month (in a revised anniversary edition, with some new material added). This book is a classic in the literature on how to manage large software engineering projects. (In fact, it may be the only classic in the literature on how to manage large software engineering projects - anybody know of any others?) It is particularly famous for the observation that, when a software project falls behind schedule, adding more personnel to the project doesn't help - it frequently causes the project to fall farther behind schedule.

There's a lot to like about the book, but there are two minor-ish annoyances that I must get out of the way before I go on to praise it.

First, I know that this might reasonably be expected in a book that was written in 1975, and which is titled The Mythical Man-Month, but this book should have: "Warning: Gratuitous Gendered Language" printed on the front cover. I'm really okay with the occasional generic "he", but Brooks practically seems to go out of his way to use "he" and "man" and so forth. It really grates after a while. Especially when he keeps writing sentences like, "One rarely controls the circumstances of his work." Huh? Why did one bother to use one if one was then going to use "his" as his possessive pronoun? The possessive form of "one" is "one's". There's a copy-editor at Addison-Wesley what needs a smackin'.

Second, the book was written when mainframe computers were the thing, interactive programming was a new-fangled thing, and an operating system that took up 400K was considered a bit of a memory hog. So, some of the specific observations on methodology now seem a little bit quaint.

However, once you get over those two flaws, there's a lot of good stuff in the book. One major observation is that software projects always run late, because no one ever allots enough time in the schedule for debugging. (Brooks says he uses a rough estimate of about 50% of the total project time for testing and debugging.) That seems true to me. Of course, I'm unlikely ever to create the schedule (or even be asked for my input on a schedule) for software product, but perhaps I can slip a hint to a few software development managers.

The second observation is the one that more or less made the book famous: that you often can't make a software project go faster by adding more workers to it, and that often, more workers will actually slow down a project. Brooks gives a couple of reasons for this:

• When you add a new worker to a project already in progress, you have to train them and get them up to speed, and this training time can actually amount to a significant percentage of the project schedule.


• Not all projects are partitionable into self-contained tasks that can be done by separate people. Also, complex projects often involve tasks that are sequential. (For example, testers cannot start testing until at least some code has been written.)


• And what I think is the real kicker: as the number of people on a project rises, the communication burden rises.


And now I have to go to lunch, so I'll try to add more thoughts later!