The Mythical Man-Month at 40

The Mythical Man-Month is forty years old this year. I read it for the first time early in my career, because everyone said you had to, and I remember thinking it was a lot of old stories about IBM mainframes with a couple of good lines in it. I reread it over a few evenings this month, after about ten years of actually running teams, and it’s a much better book than I gave it credit for. It’s also more wrong in places than people who quote it admit.

If you haven’t read it: Brooks managed the development of OS/360 at IBM in the 1960s, one of the biggest software projects anyone had attempted, and it was late and over budget in most of the ways a project can be. The book is his attempt to work out why. I have the 1995 anniversary edition, which adds his “No Silver Bullet” essay from 1986 and a new chapter where he goes back over the original and says which parts he still believes.

What holds up

The title essay holds up completely. Men and months aren’t interchangeable, because adding people adds communication, and the number of pairs who might need to talk grows as n(n-1)/2. Five people have 10 pairs, ten people have 45. New people also need training from exactly the people who are most behind. Hence Brooks’s law, which is a direct quote: “Adding manpower to a late software project makes it later.” There’s also the line about the bearing of a child taking nine months no matter how many women are assigned, which I’ve used in more planning meetings than I want to admit.

I’ve watched this happen twice from the inside. The second time I was the one who asked for more people. We added three engineers to a project that was six weeks late, and it shipped about ten weeks late, and the original team spent much of that time answering questions. What I should have done was cut scope, which is the answer Brooks returns to as well, and which management (me) didn’t want to hear.

His schedule rule of thumb is still about right too: a third of the time for planning, a sixth for coding, a quarter for component and early system testing, and a quarter for system testing once everything is in hand. People laugh at “a sixth for coding” until they look at where their last project’s time actually went. Ours was close.

And the chapter on schedules slipping has the line I think about most: “How does a project get to be a year late? … One day at a time.” Big slips are rarely one disaster. They’re a long run of days where something small went wrong and nobody thought it was worth raising. His fix is milestones that are sharp enough that you can’t fudge them, “coding 90% done” doesn’t count, and a boss who doesn’t panic when you report slippage, so people keep reporting it. That second part is still rare.

What doesn’t

The surgical team, Harlan Mills’s idea that Brooks champions, is one brilliant programmer doing all the real work, surrounded by a copilot, an administrator, an editor, a toolsmith, a tester, a “language lawyer” and a couple of secretaries. Some of those jobs have just disappeared, because version control, compilers and the web replaced them. And I’ve never seen the core idea work well. Building a team around one star makes them a bottleneck, and everyone else’s job gets boring. The teams that work best for me are small groups of people who can all do most of the work, which is closer to what Brooks says elsewhere in the book about keeping teams small than to the surgical team itself.

“Plan to throw one away; you will, anyhow.” I quoted this for years. In the 1995 chapter Brooks takes it back, more or less. He says it assumed the waterfall model, where you build the whole thing and then find out it’s wrong, and that he now prefers growing a system incrementally, so you’re always throwing away small pieces instead of a whole system. That’s basically where most of us ended up too, and it’s nice to see him get there first and say so plainly.

He also takes back his argument against information hiding. In the original he wanted every programmer on OS/360 to be able to see every interface and implementation detail. In 1995 he says Parnas was right about information hiding and he was wrong. I find it pretty great that one of the most quoted books in the field has a chapter where the author goes through it and lists his mistakes. I’d like more books to do that. I’d like more blogs to do that, honestly, including this one.

No Silver Bullet

The 1986 essay is the other thing people quote, usually as “there’s no silver bullet” without the argument. The argument is that the hard part of software is the essential complexity, the problem itself and getting the specification right, and that most improvements, like high-level languages, time-sharing and better tools, attacked the accidental complexity of turning a design into a running program. Once the accidental part gets small enough, no tool can give you an order of magnitude, because the essential part is most of what’s left. It’s a good argument. I’d quibble that some accidental complexity has come back with every new platform. Anyone who has set up a modern JavaScript build lately will know what I mean. But nearly thirty years on, nobody has a bullet, so it’s hard to say he was wrong.

Conceptual integrity

The idea from the book I use most in my own work is conceptual integrity. Brooks argues that it’s the most important thing in a system’s design, that a system should look like it came from one mind, even if many people built it, and that you get that by having a small number of architects who decide what the system does and many people who decide how. He’s careful to say this isn’t an aristocracy, the implementers have plenty of creative work. I’ve found it applies to APIs and products much more than to whole operating systems. Every API I’ve liked using had a small number of people saying no to things.

Is it worth reading in 2015? Yes, the anniversary edition, and read chapter 19 (the 1995 retrospective) right after the original chapters, not at the end. The mainframe details are dated and some of the team structures are from another world, but most of the problems in it are the ones I had in planning meetings this month.