The myth of many hands

Jun 11, 2018 | Perspectives in Engineering

Fred Brooks is a rebel.

In his 1975 book The Mythical Man-Month, Brooks observed the impact of adding people to late software projects. The simplified version of his observation became known as Brooks’ Law: “Adding human resources to a late software project makes it later.”

I’ve heard this law quoted often but only in jest by programmers who failed to meet a project deadline. As they look back over the project, searching for root causes of the failure, this law is often trotted out as a sort of joking excuse.

Yet, after 25 years working in and with software teams, I have yet to hear a manager of a late project say, “Hmm… The worst thing I could do is add more people. Brooks’ law cautions me that adding people will actually make the project later!”

I’ve also never heard a manager of a late project look back on it and comment, “My big mistake was adding more people to the project. That just made things worse.”

Unfortunately, it appears that Brooks’ Law has become an internet platitude, a moral saying that contains truth but is largely disregarded.

Why Brooks’ Law is (mostly) ignored

“Many hands make light work” – John Haywood (1497-1580)

It’s counterintuitive

When we’re young, we learn to work in various situations. Usually that work is done with our hands, arms and feet, and it’s usually completed faster when more people work together. For example, raking a large yard of leaves is faster with four people than with two and weeding a flowerbed is faster with two people than with one. This assumes, of course, that there are enough rakes and trowels for everyone to have their own.

Early on we learn a formula for work that looks like this: “If X people take Y days to finish Z tasks, then (X*2) people will take (Y/2) days to finish Z tasks.” It’s even a common math story problem in school!

Now, writing software doesn’t seem much like raking or weeding, but that old formula is hard to shake. After all, it’s so darn logical!

In actuality, many of us secretly embrace a different law than Brooks’ law, which we could call Skoorbs’ Law: Adding human resources to a late software project helps it finish on time.

This might sound silly, but since it’s how we act, it might as well have a name.

We’re under pressure

A senior director of project management at a Fortune 1000 company interviewed for this story reports, “Executive management’s first question about late projects is almost always: “Can we add more people to the project?” Our answer is usually, “No, the nature of the project is such that adding people won’t get it done faster.” While this might not be a popular answer, we understand why they ask the question. Adding people may be the most intuitive move to take, yet it’s often a bad idea.”

When projects are late there’s immense pressure to take steps to get the project back on track. When this pressure comes from non-technical executives, it can be difficult to resist – and futile to explain that software “doesn’t work that way.” In many organizations, doing something is better than doing nothing, as it shows we’re working hard to fix the problem.

In many organizations, doing something is better than doing nothing, as it shows we’re working hard to fix the problem.

Additionally, it feels safe to add people to a late project, because it’s hard to imagine it will make things worse. Yet that’s exactly what Brooks’ Law predicts.

Recall that Brooks’ Law does not state…

  • Adding human resources to a late software project has no effect.
  • Adding human resources to a late software project has a marginal effect.
  • Adding human resources to a late software project has an unknown effect.

Instead, it states that adding human resources to a late software project has a negative effect. This one management activity, meant to help, will cause the project to deliver even later than expected.

The law is at once profound, provocative, and a bit upsetting.

Someone got lucky (or thinks they did!)

Companies have their own mythology. Stories about project successes often find their way into the cannon of myths and become local legends. Like many such laws, Brooks’ Law isn’t absolute. Managers regularly add people to late projects, and some of those projects finish on time. As they say, luck happens.

Unfortunately, confirmation bias might be working against us. Confirmation bias is the tendency to interpret information in ways that confirm our own beliefs. This can easily impact how we view the outcome of a project. For example, if Mary decides to add a programmer to her late project, and the project finishes on time, she may see this as a confirmation that Brooks’ Law is a fallacy.

The truth is that, before GitPrime, it’s been very difficult (impossible?) to measure the impact of a team member added late in the project, either good, bad, or indifferent. Yet confirmation bias, past luck, and local legends can quickly create a belief that Brooks’ Law is an antiquated axiom from the past.

Loopholes

Fortunately, there are some loopholes in Brooks’ law, and once you know them, you can use them.

First, if you see a project is off track, add resources quickly. Adding people at the 25% or 50% mark allows them to come up to speed and spend time contributing to the project. Fred Brooks cited the time it takes for a new programmer to come up to speed, ramp-up time, as an oft-overlooked factor.

While adding more people early in a project may appear wasteful (you may not be certain yet that you need them), there is always the option to remove them later if they aren’t needed.

This brings us to the second loophole: padding. Pad the number of people you think you need by one or two, just in case. And of course, pad the project schedule. Estimates, after all, are just guesses.

As Jerry Weinberg states, “Consider your best-case estimate for when the project will be done if everything goes perfectly. Have you ever seen anything go perfectly? No, this logic tells us that your delivery date must be later than that.”

Add only “the best” people. I don’t mean the rockstar programmer, or the smartest person on your team. “Best,” in this case, refers to three very project-specific attributes:

  • Has worked with the team on significant projects in the past and has good relationships with team members
  • Knows the code base
  • Knows the problem domain

These three factors will have a huge impact on the outcome of adding someone to a project, especially a project that’s already underway (read: late).

Late projects are often full of chaos, miscommunications, stress, responsibility hand-offs, and a frantic pace. This is the worst possible environment for creating new trust relationships and getting a new member to gel with a team. In fact, one of the reasons Brooks’ Law is true is that the team will spend a great deal of time trying to bring the new person up to speed and figuring out whether they can trust them. This puts everyone farther behind.

Someone the team knows and trusts, maybe someone they have worked with before, is your best bet. In fact, this is an excellent time to ask the team, “If we could add someone to the team, who would you like that to be? What could they do to contribute to the project?” The team is in the best position to know, and they’ll be most accepting of a new person if they have input on the decision.

Roles and work partitions

Pulling weeds or raking leaves are examples of work that can be partitioned between people. Of course, any parent with two kids and one rake knows a shortage of tools can be a recipe for trouble. Only one kid can take the rake at a time, which causes strife between team members (and everyone else!).

If you do choose to add a new member, discuss with the team which pieces can be partitioned, and determine whether you need to obtain more rakes so everyone can be productive. You might feel you know exactly how to divide the work, but your team will probably have better ideas.

Don’t forget that the addition of a new project member also sends signals to the team about how others perceive them and their work on the project. You may be sending the message that they’re somehow not good enough. This makes it doubly important for the new person to be “pulled in” by the team rather than “pushed in” by management. Pushing in a new team member without the team’s buy-in may send the signal that the team is not trusted by management, is not capable of finishing, or lacks other qualities. This can create resentment or hostility, resulting in a dramatic loss of focus and productivity.

Conclusion

Brook’s Law reveals fundamental truths about building software: technical teams are highly dependent on each other, the work is often tightly coupled and difficult to partition, and positive trust relationships among team members is a key factor to success. However, Brooks’ Law is not a constant – like the speed of light – but a guide – like highway speed limits. Following it will keep you out of trouble most of the time, but in special circumstances it’s appropriate to break it.

Padding for the unexpected, adding the right people, taking time to find out who should be added (and when), and partitioning work allows you to add people with fewer problems and will give your late project the best chance of being turned around.

 


 

Marcus Blankenship

Marcus Blankenship

Marcus Blankenship specializes in helping technical managers and leaders create high-performing organizations. Get his lessons and resources to be a great engineering manager.

Get Engineering Impact: the weekly newsletter for managers of software teams

Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.

Get the Guide on Data-Driven Engineering Leadership

Gut feelings in engineering are being replaced with data. By analyzing over 7 million commits from over 85,000 professional engineers, we share how you can incorporate concrete metrics to guide engineering productivity.

Success! Please check your email for your download. You might also be interested in Engineering Impact: the Weekly Newsletter for Managers of Software Teams. Keep current with trends in engineering leadership, productivity, culture and scaling development teams.

Share This