Fred Brooks, and what Man-Month taught me

Fred Brooks died last Thursday, the 17th, at home in Chapel Hill. He was 91.

Most people know him for one book, and I’ll get to it, but the list is longer than that. He managed the development of IBM’s System/360 and then of its operating system, OS/360, in the 1960s. He said in interviews that the most important decision he made there was the 8-bit byte, which every computer you’ve used since has inherited. In 1964 he founded the computer science department at the University of North Carolina, and he stayed there for the rest of his career, much of it spent on interactive graphics and virtual reality. He won the Turing Award in 1999.

And he wrote The Mythical Man-Month, in 1975, about what went wrong on OS/360. I reread it in 2015 for its fortieth anniversary and wrote that it was a better book than I’d given it credit for the first time, and more wrong in places than people who quote it admit. I still think both. On Friday I got the anniversary edition down and reread the 1995 chapter, where he goes back through the original and says which parts he still believes.

That chapter is what I think of first when I think of him. It’s very unusual for a famous author to go back to the book that made him famous and say, in print, that he was wrong. He took back “plan to throw one away”, because it assumed the waterfall model. He said Parnas had been right about information hiding and he’d been wrong. He did it without any fuss, as if being wrong and saying so was just a normal part of the job, and I’ve been trying to get better at that for most of my career. I wrote a post last year that was mostly a list of admissions, and that chapter was the model for it, though I didn’t say so at the time.

The idea of his I use most isn’t the famous one. Brooks’s law, that adding people to a late project makes it later, is true and I’ve lived it. But the one I reach for every week is conceptual integrity, the argument that a system should look like it came from one mind even when many people built it, and that you get there by having very few people decide what it does. Every API I like using, and every product, has someone saying no.

The other essay worth rereading this week is “No Silver Bullet”, from 1986, which argues that no single tool will give us an order-of-magnitude improvement, because most of what’s hard about software is the essential complexity of the problem, not the accidental complexity of expressing it. I’ve been using an AI code-completion tool every day this year, and it’s very good at the accidental part. It doesn’t know what the system is supposed to do. Brooks would have found that unsurprising, I think, and probably interesting.

If you’ve never read the book, the 1995 edition is the one to get. I’m going to put mine back on the shelf a bit closer to the desk.