The Mythical Man-Month

the review

Ok, I confess, I must be the one guy I know who hasn't read Fred Brook's "The Mythical Man-Month", although I have heard dozens of people say how good it was, and (this is especially painful) I've even quoted the book. The book I didn't read. Ouch.

Read any great programming books lately?

How about a great programming book that you know is still going to be great 25 years from now?

There are only a very few books that could fit that category, and after finally reading it, I know that "The Mythical Man-Month" is one of them.

Sure, for a book written in 1975, it's starting to show its age. All those sections about counting bytes in a program, or having somebody different to run the compile than the person writing the program were quaint. And when Brooks goes into the wonders of "modern" text processing -- being able to have documents printed and on somebody's desk first thing in the morning! -- it was downright funny.

In fact, by lightening my reading style, no longer reading as if I were studying and reading more for pleasure, I found big parts of the book very enjoyable from a how-did-they-do-it-then standpoint. The IBM System/360 sounds like quite an achievement for its time. Lots of things we take for granted were just getting going back then.

But what was more amazing than hearing stories of old-fashioned development efforts, how different everything was, was the surprising fact of how many things that were mostly the same then as they are now.

Brooks is weakest where we as programmers always are weakest: trying to take our skills at programming and shoving them on to how to organize projects. Many of his ideas probably sounded great at the time, and I know that his 360 project was well-regarded, but experience has shown us that these ideas didn't work so well consistently (Ever heard of a "Language Lawyer" on a project? 'Nuff said)

But Brooks is strongest where great architects always are: he's able to step back from the problem of trying to organize groups of programmers into a larger project and make observations that are terribly obvious, yet also terribly counter-intuitive. He's the guy on a really great project who looks at the problem, restates it, and everybody sits around with their mouths agape. Damn! Why didn't I think of that? I love it when that happens.

Every three or four pages I found myself reading really good observations that by now have become lore in the programming world. The idea of comparing software development to construction, the idea the man-months are not fungible, the idea that adding people to a development project will actually make it run later, the idea that communications issues increase in an exponential fashion as people are added -- I could go on, there were scores of these gems.

I came up through the programming world hearing all of these, usually third or fourth-hand. Some of the "famous" books I've read had parts that were lifted almost directly from MMM, which appeared decades before! In a way I feel almost cheated. I wish I would have started here, then moved to the other books, instead of the other way around.

When you become a parent, you finally understand growing up, because you see yourself both when you were a kid looking at parents and as a parent looking at kids. There's this powerful echo-chamber effect you get the first time you say something to your kids that you yourself heard told to you. Likewise, when I read MMM I was powerfully moved -- completely accidentally on the author's part -- at how these same themes have been with programming for the last 45 years. And how they are probably going to be with us for the next 45 years.

I can't give MMM my fullest recommendation though, for the simple fact that Brooks covers large-scale development and other things that didn't turn out to be quite so useful with the same surety as he does the other stuff. For the noob, it can be difficult to tell the good stuff apart from the not-so-good stuff. There's a lot of structured programming in there, and there's a lot of "since we can logically divide the task this way, we must also logically divide the workers this way" I'm probably a bit of a harsher critic than most, having seen multiple 1000+ developer projects, and all the things that go wrong with them could probably fill another book. MMM is best when it's dealing with the general types of problems we face when trying to organize ourselves as programmers, not when it tells us the exact details of how to make every large project sucessful.

Having said that, this is an excellent book for anybody who wants to keep from making the same old mistakes that keep getting made over and over again. It's a "first" book, meaning you start here and go forward. Thinking about becoming a tech lead or one day maybe a PM? The line starts here. Don't do like I did and hear all of this secondhand from other authors. Brooks has some of this stuff nailed. He's the guy all those other great authors copy from. Excellent read.

the buzz