Understanding Brook's Law: Why More Hands Don't Always Help

This law were defined by Fred Brooks in 1975 on his book "The Mythical Man-Month". It could sound counterintuivive at first glance, but further into this article you'll see why it makes total sense. This law became a classic principle in the world of software engineering. Let's dive more into it.

Practical Application: When Brook's Law Makes Sense

Imagine you are managing a small team developing a new application. You are a behind schedule, so you decide to hire five more developers to help speed things up. But instead of seeing progress faster, you find yourself spending more time onboarding and training the new developers, explaining about the project, and solving misunderstandings. You keep missing deadlines and frustration grows among the team and also the stakeholders.

Brook's Law suggests that sometimes the answer to a delayed project isn't more people, but better organization, communication and making your processes better.

Key Points of Brook's Law

Let's shine some light on the key points to explain this law better:

Learning curve: Every new member that joins the project need time to learn how everything works. In the beginning they won't contribute as much as the other ones or none at all.
Communication complexity: The more people on a project the more frequent and more lines of communication are needed. We all know that clear and concise communication is key but in late projects that becomes difficult. This increases complexity and can lead to misunderstandings and wasted time.
Task division: Not all tasks can be easily divided – or divided at all – among multiple people. Some problems are sequential and cannot be parallelized.
Management overhead: Managing more people requires more time and effort, which can distract managers from other important tasks. I'll write more about this subject and the Bermuda plan will be a good complement to this point.
Interdependencies: Many software modules depend on each other. Coordinating between different parts of the code can become a nightmare as more developers are involved.

In summary, adding more developers to a delayed project can paradoxically cause even more delays. Instead of just increasing the size of your team you can work to improve processes, eliminage obstacles and sharpen the team communication.

Instead of simply increasing the team size, it might be more effective to focus on improving existing processes, eliminating obstacles, and enhancing communication within the team.