Brooks' Law in Software Development and Project Management

Is it always better to have more people on a specific project ?

Sometimes, we think adding more resources or people power is always the right solution to speed up a process.

However, is it really the case ? Lets explore some key concept about Brooks' law, explaining how increasing the human factor on a project can have other unwanted results.

What is Brooks' Law ?

It is a phenomenon observable in software engineering and project management where adding people power to a large and generally unsupervised in terms of task disivibility is going to delay such project instead of speeding up the completion.

Key factors and explaination

From Brooks, the following points captures the general (simplified) comprehension of the rule:

1. There is a learning overhead when introducing new actors to a project, especially in software engineering. Introductions of bugs from actors with few experiences on the project can delay progress. It is important to remember that it is not necessarly in terms of overall seniority of a developper's career by example, but rather his time on the specific project and especially if the project is special and was never done before.

2. When working on a task which information needs to be synced with others, a coomunication overhead occurs. This is due to the combination of links between actors, raising in a combinatorial rate because there is one link created for each new actor in the group.

3. Tasks needs to be divisible for the overhead to be close to none. Otherwise, work will generally be slowed down. A famous example: A baby can be made in 9 months, but it cannot take only 1 month by having 9 persons to do so.

How can we avoid this phenomenon in software engineering projects ?

From my perspective and personal opinion, here are possible actions we can take to reduce overheads on software engineering projects:

1. Having a good Agile/SCRUM process and divide tasks without leaving dependances with one-another. Otherwise, actors will have to communicate a lot for trivial information, and you will have to manage a lot of Merge Conflits (GitHub).

2. Offering a global communication channel for genral questions. This way, we reduce the combinatorial aspect of links between multiple actors of a group.

3. Creating a strong documentation process to reduce learning curves and trivial questions of new developers. They will be able to learn and check by themselves when needed, reducing the use of communication channels.

4. Having a balanced management guideline, sometimes having a rigid management framework can reduce or alter a project's progress because of all the overhead it produces. Of course, having no rules will reduce considerably the quality of the software codebase and render metric compilation ineffective. Thus, having a balance between processes and people's autonomy is important, and it motivates the reason why Agile/SCRUM is so popular and effective in practice.