Beware the long arm of Brooks’ law
Your software project is running late. Deadlines came and left a while ago now, and yet your software is nowhere near a finished state.
So, what do you do? Do you move most of your team on to the next project and leave a few to finish off this delayed one? Or do you add more people to the team to get the tardy project finished faster?
If you choose the latter, you may get caught by the long arm of Brooks’ law. But what is this law of software development, and how far-reaching is it?
The law
Brooks’ law states that adding more people to a late software project makes the project later. It originates from Fred Brooks’ 1975 book The Mythical Man-Month.
In his book, Brooks argues that cost varies with the number of team members and months a project takes. Progress, however, doesn’t.
So, Brooks posits that the ‘man-month’ is not a good unit for measuring the size of a job because it suggests that team members and months spent are interchangeable. (They aren’t.)
Just as adding more chefs doesn’t reduce the amount of time a cake needs to bake, adding programmers won’t reduce development time.
The causes
According to Brooks’ law, adding people to a late project lengthens the time that a project needs. But why does this happen? There are two key reasons that Brooks supplies.
- Ramp up time
First, there’s the ‘ramp up’ time. This is the time needed to bring new people up to speed on the late project before they can become productive.
- Communication overheads
Second, adding people to a project means adding to the communication overheads of the project. In other words, as more people join the project, more time is spent finding out what everyone else is doing and coordinating efforts.
What Brooks’ law means for your development
So, if you are falling foul of Brooks’ law, what does it mean for your software project?
For a start, adding people doesn’t mean that you’re addressing the cause of the lateness. It assumes that the problem lies with the development team. However, there are many reasons a software project might be late.
For example, a third-party issue might hold a team back. Or a lengthy review process. Or delayed specs. Adding additional development team members doesn’t fix any of these things.
Too many code cooks
Alongside not addressing the cause of the delay, ignoring Brooks’ law increases the burden placed on your existing team. Now, they must spend time and effort bringing the new people up to speed with the project. This is time they could spend on getting the project closer to completion.
Plus, adding people to a project that doesn’t need them leads to overcomplication. The project is late, so everyone must look busy. But if the remaining tasks only need a few team members to complete, what can everyone else do?
This last-minute overcomplication can lead to the addition of new code and features, creating additional hurdles to completing the late project. (And risking feature creep to boot.)
In short, too many cooks spoil the broth, which still doesn’t cook faster for their combined efforts.
Outrageous oversimplification
Brooks said himself that Brooks’ law is an ‘outrageous oversimplification’ — yet it captures the heart of the matter. However, this means that there are still considerations to make.
Brooks’ law, for instance, only applies to projects that are already running late. Adding people to a project early on can help keep control of a project that’s threatening to run late.
So, your scheduling is an important consideration. Is your software project truly late, or was your scheduling too ambitious?
Another consideration is the role of the people you’re adding to the team. Some responsibilities need less communication and ramp up time before new people are productive.
For example, if the role is extra testing, the added person isn’t going to need intimate knowledge of the code. So, time isn’t wasted explaining to them.
The long arm of Brooks’ law
The more complicated the project at hand, the higher the chance that the long arm of Brooks’ law will catch you. If you need to stock shelves, adding more people to the task will see it done faster. After all, it doesn’t demand communication or ramp up time to get someone started on the task.
But, for something as complicated as software development, the long arm of Brooks’ law is far-reaching. And it can cause more than an extra delay to your project.
So, are you falling foul of Brooks’ law?
Useful links
Overengineered software and the Juicero problem
Software project estimation: handling the dreaded ‘how long will it take?’
