Today’s edition of Eponymy in August is Brooks’ Law. In the eponymous’s original words,
“Adding manpower to a late software project makes it later.”
Fred Brooks called this statement an outrageous oversimplification in his 1975 book The Mythical Man-Month. This book is sometimes called the bible of software engineering, because everybody quotes it, some people read it, and a few people go by it.
Brooks wrote the book based on his experiences working at IBM. In the 1970s, Big Blue was working on OS/360, the operating system for its flagship series of mainframes. Brooks observed that the total development time spent on the ALGOL compiler could not be pushed down to six months no matter how many engineers were allocated to it, and for other projects that were already running late, adding new people slowed them down even more. Brooks analyzed the failure of the projects to deliver on time and noted three key factors:
- Adding new people to a late project slows down the experts already on the project, by diverting their time and resources towards onboarding the newbies. However, inexperience prevents these resource diversions from paying off immediately; there is always some amount of ramp-up time necessary for a worker on a project to contribute meaningfully.
- Communication overhead grows at an increasing rate as new members are added to a team. The amount of time that each worker must sync with all the others grows with more people added (this is why the ideal size for a software development team is five to seven: Communication overhead grows greatly at any team size above seven members)
- Tasks in software development are not infinitely subdivisible. Even in divisible tasks, there is overhead associated with too much subdivision, as workers often have to integrate their work with that of others.
There are several ways to mitigate the impact of Brooks’ phenomenon. The simplest one is to not have late software projects: using an iterative development model, a team can guess what they might be able to do within a span of a few weeks, attempt it, and what features cannot be done on time are pushed off. This gives a much clearer picture of what sort of scope is realistic for the project. Another positive step is not using all of the team’s time to write the core software; instead, divert part of that time to writing automated tests and documentation, which will help onboard new people if needed. Finally, train people before you need them. This should be obvious, but training budgets are slim to nonexistent in most companies these days, and it’s a serious problem leading to everything from bad hiring practices to crisis-oriented development (where you prioritize tasks by taking on the biggest emergency first, and there are never a shortage of emergencies).
[ed note: updated 2026] At the time of the original writing, Fred Brooks was a Professor Emeritus in UNC Chapel Hill’s Computer Science department, which he co-founded. Brooks passed away in 2022, which I noted at the time on my Fedi feed.