If you haven’t read The Mythical Man-Month by Frederick Brooks, you really should. Although it was published in 1975, it’s a classic, and widely considered a must-read for anyone involved in software development, particularly in the management of software projects.

Yesterday we looked at ramp up time as one reason that the natural tendancy to hire more people hurts, rather than helps, team performance in the short term.

Another factor in this question is that of overhead. Every new team member adds overhead, particularly communication overhead.

The Lighthouse blog illustrates this with a famous chart:

But in the world of software engineering, it can be much much worse than this. Let’s consider merge conflicts.

If you’re not already doing real continuous integration, or worse, GitFlow, you’re probably very familiar with merge conflicts. You know how it goes…

Bob edits a file to add his new feature…

-games = ["solitaire", "tetris", "free-cell", "minesweeper", "duke nukem"]
+games = ["solitaire", "tetris", "free-cell", "minesweeper", "duke nukem", "lemmings"]

But at the same time, Alice removes an obsolete feature…

-games = ["solitaire", "tetris", "free-cell", "minesweeper", "duke nukem"]
+games = ["solitaire", "tetris", "minesweeper", "duke nukem"]

and…

I’ve seen teams where more time was spent resolving conflicts than writing code. And what’s worse than the wasted time, conflict resolution is very difficult to do correctly, and often leads to improper merges: missing code, duplicate code, or the dreaded <<<<<<< HEAD smack in the middle of your file.

What to do? As always, there’s no one-size-fits-all answer, but here are some things to consider:

• Reduce communication overhead by limiting team size
• Prefer multiple small, focused teams, over a large, generalized teams
• Consider whether your constraint is actually merge conflicts, or some other process, and not a lack of developers
• If you’re using GitFlow, stop!
• If you’re not using real CI, work to make your PRs smaller