Why More Developers May Slow Your Project: Insights from the Mythical Man-Month
Although intuition suggests that adding more developers speeds up delivery, software projects often suffer longer cycles due to communication overhead and coordination costs; the classic ‘Mythical Man-Month’ explains why a small, skilled team can be more productive than a larger, less coordinated one.
Imagine moving 10,000 bricks: one person moves 1,000 per day, so it takes ten days, but ten people finish in one day. This simple logic fails in software development because adding people introduces communication overhead.
In large IT projects, the more people involved, the longer the development cycle. Projects with hundreds of participants often spend a month or more just on planning, while a small team can complete most of the work in the same period.
The basic unit for measuring work in software projects is the person‑month , defined as the amount of work one person can finish in one month. However, 20 people for ten months (20 person‑months) does not simply double the speed of 10 people for ten months; the relationship is not linear.
With 20 people, the number of communication pairs rises to 190, compared with only 45 pairs for 10 people, dramatically increasing coordination cost. Much of the time is spent on meetings and misunderstandings, leading to rework.
Consequently, larger teams do not guarantee faster progress. When a project falls behind, managers often add staff, but new members need time to learn the project, and rushed onboarding can degrade quality and increase testing effort.
The classic book The Mythical Man‑Month by Frederick P. Brooks Jr. explains these phenomena. It shows that a person‑month is only interchangeable between people and time when tasks are perfectly partitioned and require no communication.
In real software projects, tasks are divided among designers, developers, testers, and operators, each requiring coordination, which erodes the time saved by parallelism.
Studies indicate that top programmers can be ten times more productive than average ones, so a small, elite team often yields the best results by minimizing communication overhead while maximizing output.
For very large systems, a small team cannot handle the sheer volume, so additional staff become necessary, but the optimal structure is a chief programmer (or lead architect) supported by a deputy who collaborates closely on design and implementation, while other developers and managers work around this core.
This model combines the completeness of a few minds with the productivity of many, while keeping communication costs low.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Programmer DD
A tinkering programmer and author of "Spring Cloud Microservices in Action"
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
