There we were, like museum specimens in our all-glass conference room. We sat there, attempting to create a plan that would complete a project in three months rather than the five that any fully functional software team our size would normally require. Sound familiar?
Brooks Law (created by Fred Brooks in The Mythical Man-Month) is typically described as "adding human resources to a late software project makes it later". Brooks goes so far as to say that adding additional team member makes the project take more time, not less. At first blush this may sound counterintuitive, how could adding an additional team member not speed up the project? Let alone cause it to take longer? There are three reasons or issues that Brook uncovered when he created this law.
1. "Ramp Up" time
Creating Software isn't a simple process, it requires complex engineering endeavors to solve equally complex problems. As a result, any new team member must take his own time, and the time of other team members to understand the complexity and logic within the software being created. This reduces not only the productivity of the new team member but also the entire team as they take time to bring the new member(s) up to speed. Even if the new team member understands the system pretty well, they are still likely to create code that will result in bugs and thus time to fix these bugs.
2. Communication overhead
The second point is a simple concept with a healthy dose of mathematics behind it — communication overhead. This is the time spent by the team communicating with other team members about the tasks they are working on. This communication is critical as it keeps everyone in sync. However, it leads to a problem known as a combinatorial explosion. Each new person added to a project exponentially increases the number of communication paths within the entire team. As a result, more and more time is spent communicating about tasks and less time actually completing them.
Side note: In fact, too much communication within any team can be symptomatic of the lack of a clearly communicated and understood vision.
3. Limited divisibility of tasks - Not all tasks are alike, Brooks explains that while it takes one woman nine months to make one baby, "nine women can't make a baby in one month". His point is that while some tasks may be divisible, and therefore benefit from more people working on them, such as cleaning a hotel, this is only true up until the additional people cleaning a hotel would get in each other’s way.
It can be tempting to throw more developers and architects at a problem, trusting that a surplus of man power must surly resolve the issue or complete the project. If you find you (or a manager) is tempted to add more personnel to a team or project, then it’s time to diagnose where the issue is actually coming form. Could it be that the product owner/manager is not properly planning out the work? Or possibly upper management set uninformed and thereby unrealistic goals? Did sales make promises to clients without consulting product? Or is the quality of development low resulting in more bugs or longer cycle times for your tickets? Perhaps technical debt has been put off and is now causing real headaches and delay. Instead of assuming adding more people will fix the timeline, it’s better to focus on understanding the source of the ‘late software project’. An architect I used to work with once told me, “If you focus on the mechanics of the problem, the solution becomes clear.”
Next time you’re tempted to call the recruiter, or “re-allocate” resources internally, take a minute to deeply understand the problems at play, consider both the cost associated with bringing in new team member(s). Because whatever the problem, and whatever the solution, bringing on new team members to an already late project will require you to deal with the three issues of Brook’s law.