I found The Mythical Man-Month on one of those lists of books every programmer should read. But, I was a bit apprehensive when I saw it was published in 1975 (Two more editions were published in 1982 and 1995, but I only had the 1975 edition on hand.). What could a book written that long ago teach me about software development today? Surely everything’s changed since then (No fewer than five hundred million front-end JavaScript frameworks have been developed in that time.). Despite my doubts the book had a cool name, a cooler cover, and wasn’t so long. Moreover, at the time I was in a car without an internet connection, so my options were limited.
What kind of animal is this? It has the face of a bear or maybe a badger. In either case, the tail is too long. Face of a bear, tail of an otter, posture of a T-rex. After hours of contemplation I’ve decided it’s either some kind of prehistoric proto-bear or a hulking bear-otter hybrid from a very grim future.
The author, Frederick P. Brooks Jr., was the Chairman of the Computer Science Department at UNC Chapel Hill and an engineer and manager at IBM. The book centers on lessons Brooks learned while leading a team developing OS/360, an IBM mainframe operating system. Unlike other books on most read lists, this book won’t teach you how to name your variables or format your code. It’s focused on the human element of programming. The driving idea behind the book and the source of its title is that, at least when it comes to software development, “Many hands make light work” is fake news. A project estimated to take one month with one developer won’t take two weeks if you add another. It might take two months or maybe longer. The problem is that communication overhead increases as you add members to the team. Brooks elaborates on this, saying, “Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work. The training cannot be partitioned, so this part of the added effort varies linearly with the number of workers.”
The book won my approval early on when Brooks muses that software engineers might all be a bit too optimistic. By the time I read this book, I’d already worked as an engineer for a couple of years, and especially in my first year, I was definitely guilty of undue optimism and time estimates that were nowhere near realistic. When the most complicated thing you’ve built is a calculator or a website that says “Hello, World!,” it’s easy to assume everything will always go well. But, as Brooks points out, the chance of everything going smoothly on a large project is pretty slim. He says, “…there is a probability distribution for the delay that will be encountered, and ‘no delay’ has a finite probability. A large programming effort, however, consists of many tasks, some chained end-to-end. The probability that each will go well becomes vanishingly small.”
In the third chapter Brooks presents a software engineering team modeled after a surgical team that he credits to Harlan Mills, a Professor at Florida Institute of Technology. Leading the team is, of course, the surgeon. He’s the mastermind, and the system should be a product of his mind alone. Surrounding him is a team designed to make his work easier, in charge of documentation, a tester, and so on. He contrasts this with a hog-butchering team, where each individual hacks away at the problem. I’ve definitely worked on some hog-butchering teams. That was no fun. Different people work on the same component, and one engineer’s changes conflict with another’s, whose changes conflict with yet another’s. Soon enough nothing works and there’s plenty of blame to go around. The projects I enjoyed the most (and those that worked out best) are ones where each person’s role was clearly defined.
The next chapter begins with a description of European churches. At first he describes a set of confused monstrosities, the result of subsequent generations of architects trying to modernize and “improve” upon what came before. What’s left is a ugly mish-mash of architectural styles — a Gothic arch here, a Norman baluster there, and a few Pokemon cards thrown in for good measure. He contrasts this with the stylistic integrity of France’s Reims Cathedral, the result of “eight generations of builders, each of whom sacrificed some of his ideas so that the whole might be of pure design.” In software development the adage “a bad plan is better than no plan” holds true. So, it’s better that a project has one odd, idiosyncratic style that the whole team follows, rather than everyone trying to execute their own good but unconnected ideas.
I never expected to chuckle at an old programming book, but this one was full of surprises. Each chapter begins with a picture and an epigraph, with sources ranging from the menu of a New Orleans’s restaurant to ancient Roman poet, Ovid. Brooks has a great sense of humor, and the book is chock-full of playful bits, alongside the practical information at the core.
Discussing the futility of adding extra hands, he says, “The bearing of a child takes nine-months, no matter how many women are assigned,” and that chapter ends with the eponymous Brook’s Law, which states, “Adding manpower to a late software project makes it later.” And in another reference to Reims, he quips that “The result proclaims not only the glory of God, but also His power to salvage fallen men from their pride.”
It turns out those must-read lists are spot on, and a book from the seventies still has plenty to offer today. I strongly recommend this book, not only to engineers, but to anyone whose work requires collaboration.