This is a continuation of yesterday's post Fred Brooks "It Is a Humbling Experience to Make a Multi-Million Dollar Mistake" about Fred Brooks' experience developing the IBM System 360. Today I'll talk about the book he wrote about the experience and the lessons he drew from it.

I recommend the book The Mythical Man-Month to everyone. Despite the book being subtitled Essays in Software Engineering, I think it is (mostly) equally appropriate to IC design, and the design of many other types of large systems. Many of the lessons apply to any large complex project.

The title comes from the fact that it is a fallacy to measure large projects in man-months (or person-months as I guess we would say these days, but I'm going to stick to men since that's what the book's title uses). The reason is, as he says, that it assumes that men and months are interchangeable. Even ignoring the obvious truth that some engineers are better than others, trying to get a project done in six months with 100 engineers, is not at all the same as trying to get it done in two years with 25 engineers. A quote attributed to Brooks (not from the book) that feels all too true to those of us that have managed large engineering projects:

What one programmer can do in one month, two programmers can do in two months.

And a quote from the book (I don't think this is original to Brooks):

It takes nine months to make a baby no matter how many women you assign to the task.

When I was an undergraduate, computer science was just getting going as a discipline and it was a one-year course that you took in 3rd year (full time—in English Universities you don't study anything other than your major). As it happened, the year I did undergraduate computer science, Fred Brooks was on sabbatical at the Cambridge University Computer Laboratory, so I met him a couple of times. Once during the year, he gave a seminar on his experience, and once he gave a guest lecture in one of our undergraduate courses (operating systems?). His presentation style was as wonderful as his writing style. The book was published that same year, in 1975. I suggested it to my Dad when he asked me what I'd like as a Christmas gift that year and he wondered why I wanted a book on the male menopause when I was 21!

The book is famous for several things, most notably what he calls Brooks' Law (which he admits is a gross oversimplification):

Adding more manpower to a late software project makes it later

The reason for this is that the new people have to be trained, have to get up to speed, are probably less of a match for the project (or they would already be on it), and so on. Of course, this leaves the corollary that not adding manpower to a late software project still leaves you with a late software project.

Another phenomenon Brooks named is the "second-system effect". For many of the people working on OS/360, it was their second system after elegant systems on some of the other smaller IBM machines that preceded the 360. The second-system effect has been defined as "the tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence". For another second-system effect story, this time about Multics, see my post The Most Important Operating System Ever. No, Multics was not that system, it suffered fatally from the second-system effect. But it led to Unix, and eventually to Linux, iOS, and Android.

In the book, Brooks talks about building large industrial-strength systems, which he compares to the type of system that an individual programmer might throw together for their own use. He reckons, in the book, that it is three times as complex to build a system that can be deployed and supported with a bigger user base, and also a factor of three if the system has to run and be tested on a range of different hardware. To do both, as was the case with OS/360, those factors multiply, making it nine times as hard. But in his seminar at Cambridge, he said he then thought that those two factors should both have been five, making it 25 times as difficult to build a widely deployed scalable piece of software.

No Silver Bullet

Over ten years later (by then he was a professor at UNC Chapel Hill), Fred Brooks would go on to write a piece No Silver Bullet: Essence and Accidents of Software Engineering. This was a sort of follow-up to his earlier book, expressing his disappointment that all the problems identified in the book were largely still with us in 1986 (and, in fact, are largely still with us today). 

I won't cover everything in this piece (I've given you a link so you can read it yourself). But some of the bullet points that make it all the way to the abstract are:

• Exploiting the mass market to avoid constructing what can be bought.
• Using rapid prototyping as part of a planned iteration in establishing software requirements.
• Growing software organically, adding more and more functions to systems as they are run, used, and tested.
• Identifying and developing the great conceptual designers of the rising generation. 

Many buzzwords from today in both software and IC development, such as agile development, use of IP/libraries, minimum viable product, and so on are modern names for some of these bullet points. Many of the lessons in The Mythical Man-Month are still valid today, 45 years after it was first published.

The Mythical Man-Month has never been out of print. After 25 years, Fred Brooks updated it with a 2nd edition (and a new cover but still with prehistoric mammals in the La Brea Tar Pits).

Oh, and since I wrote about the latest Turing Award recently in my post Turing Award: Ed Catmull and Pat Hanrahan, I guess I should point out that Brooks won the award himself in 1999:

For landmark contributions to computer architecture, operating systems, and software engineering.

But perhaps the most important thing that he did was to take all the things that went wrong on the IBM OS/360 project and detail them at his own expense in this book.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.