Fred Brooks passed away this week. Depending on your age, you know him as either a luminary in the field of computing or the writer of some of the better quotes in your CS textbook. In reality, he was both.
Brooks lead the development of IBM’s System/360 and OS/360, which were revolutionary milestones in computing and the forerunner of nearly all modern systems. During these megaprojects, Brooks learned many valuable insights about how to organize software projects and he went on to publish and speak about them.
The famous maxim, “adding manpower to a late software project only makes it later” (Brooks’ Law) comes from his book, The Mythical Man Month, which everyone in CS has at least heard of. His central argument in that book is that many projects do not benefit from adding people to them.
If you’re building a sandbag wall, having more hands to fill the bags and stack them is the bottleneck so as long as you don’t outstrip your supply of sand and bags, adding more people will make the project go faster. But software projects aren’t like that. If you’re trying to ship code by the end of the month, suddenly dumping 100 more engineers into the project is going to make things worse.
It’s nonintuitive for many managers or people whose day-to-day job is not in IT, but if you think about it, the reasons make sense:
Ramp Up Time: I can’t contribute to the codebase until I learn what tools and libraries are in use, learn those tools and libraries, understand how the code is laid out, get my credentials, understand the norms of the group (everything from coding style to commit expectations), etc. All of this requires time and especially time from the existing engineers. While an existing engineer is showing me how we pull data or which database client libraries we’ll be using, that engineer is not writing code.
Combinatorial Explosion: Once I’m up and running, I now have to interact with all the other engineers. When there are four people on the project, it’s not a big deal. When there are 20 or 200, simply keeping everyone informed and communication eats up more and more of the time. One would expect that with our dizzying array of communication tools, this would be much easier. And it is easier – you can send use email or Slack instead of typewritten memos. But then others have to take the time to read them!
Not All Tasks Are Divisible: For some tasks, you need one or a few people to focus and work on them because they have specialized, domain-specific skills. As Brooks puts it, “nine women cannot make a baby in one month”. Adding more people would be the equivalent of training people for extended periods in very complex areas. This is not really about things you could learn at college or general CS but rather highly complex systems that have already been built or cases where all the domain-specific knowledge about an application is local to the team.
The Mythical Man Month has lots more insights, and the book stretches over many topics in software engineering. Brooks – a veritable fountain of fun quotes – once said it was the software engineering Bible because “everybody quotes it, some people read it, and a few people go by it”.
Brooks was a Turing Award winner and lived to the age of 91.
Related Posts:
I also enjoy using LEBs! I have an empire of little guys for VPNs, larger guys for apps, and big guys for databases and storage. When I'm not in front a screen I'm into German Shepherd dogs, quality knives, target shooting, theology, tabletop roleplaying games, and forest hiking.
I enjoy writing technical articles here on LowEndBox to help people get more out of their systems. You can find me on LowEndTalk @raindog308
Leave a Reply