<p>What I have done (and this is only subjective) is as follows:</p>

<p>When a manager thinking about a due date wishes to add people into my team to cut the time needed and seems under MMM, I first discuss with him or her on why this could be bad. My favorite analogy for this is to remind them that if one woman can have a baby in nine months, nine women won't have one baby in one month, but they'll have nine babies in nine months. The time isn't cut, just the parallel processing is better.</p>

<p>When the decision is forced upon our team, we usually try to either further divide some tasks, and when this is not possible we usually rely on <a href="https://en.wikipedia.org/wiki/Pair_programming" rel="nofollow noreferrer">pair programming</a>, where one programmer is responsible for typing, and the other dictates the code (and switching periodically).</p>

<p>The code writing itself is slower, but there's fewer typo/linting and bugs when testing because of the inevitable review done while writing. I feel the overall code quality is also a little better, but I've no metrics to support that claim.</p>

CC BY-SA 3.0
2017-06-08T10:58:18.917Z
please do, waiting for it!
Ta Mu
CC BY-SA 3.0
2017-03-04T05:31:46.457Z
I like the pair programming idea. That is actually something that could help. I might be able to explain why later based on the theory I have been working on.
Jiri Klouda
CC BY-SA 3.0
2017-03-03T12:59:50.253Z
2017-05-22T17:00:45.260Z
2017-05-22T17:00:45.260Z
Tensibai
<p>Speaking exclusively from a CI perspective, increasing the number of developers working on a project typically translates into more people working in the same branch.</p>

<p>Traditional CI systems have a scalability issue in this respect: the probability of breakages/regressions/blockages increases slowing down the integration speed and inviting smaller teams to break off and move on to child branches (i.e. further slowdowns). See <a href="https://devops.stackexchange.com/questions/265/how-can-continuous-integration-scale-for-very-large-projects-teams">How can continuous integration scale for very large projects/teams?</a>. This plays right along the Mythical Man Month concept.</p>

<p>The solution I suggest in my answer to that question, a <em>highly scalable</em> CI system would enable migration towards true CI - single branch/trunk based integration for entire greater teams (even with huge sizes). </p>

<p>With everyone of the same page, using the same automated tools/processes and the vast majority of the QA verifications automated inside the CI system itself it becomes much easier to switch roles and focus between team members. The whole development proces becomes smoother, more predictable, more relaxed.</p>

<p>Bringing new people aboard in such an environment, getting them productive simply by offloading less difficult tasks from the more experienced team members which can then take on more difficult ones is thus easier.</p>

<p>All of these can be seen, I believe, as soothing the Mythical Man Month concept effects.</p>

CC BY-SA 3.0
2017-06-18T08:56:07.490Z
It is a common illusion that a system can be improved by improving each part it is comprised of. When you study system thinking, or the holistic approach to systems, you learn very quickly that it is not true. Improving every part in a system, usually makes the whole system worse not better.
Evgeny Zislis
CC BY-SA 3.0
2017-03-04T10:05:01.213Z
In high-performing organisations, adding more developers usually means creating more independent teams who write decoupled software. This allows more people to achieve more and faster. Having them all communicate via a single integration branch is an anti-pattern and most probably will slow things down considerably.
Evgeny Zislis
CC BY-SA 3.0
2017-03-05T06:44:26.570Z
`Having them all communicate via a single integration branch is an anti-pattern` - why? If they're decoupled in the sense that they will no longer need to integrate their work then they will touch the branch in a non-overlapping/non-conflicting manner. If their work still needs to be integrated then going on additional branches will just delay and complicate the integration by deviating from the CI methodology and losing all its advantages.
Dan Cornilescu
CC BY-SA 3.0
2017-03-05T07:05:34.060Z
I think we are not agreeing on the meaning of "branch". It is fine to have one large repository, with a single branch (git, or svn), and suffer the overhead of everyone working on the same one. It is also fine to have multiple repositories where each repository has a branch that tracks that specific decoupled service. It depends on the tool, the amount of overhead it adds to commit and checkout code.
Evgeny Zislis
CC BY-SA 3.0
2017-03-05T07:42:26.870Z
Ah, sorry, yes - I'm so used to it and keep forgetting others aren't. By branch I'm referring to the high-level, generic representation of the SCM branch, it doesn't really matter which are the particularities of the actual underlying SCM system(s) as long as they're managed together in a monolithic manner. 1 big repo with a `main` branch or 10 side-by-side repos (git modules?) each with a `main` branch should be pretty much equivalent from the CI prospective.
Dan Cornilescu
CC BY-SA 3.0
2017-03-05T07:44:16.763Z
Then my statement from the first comment holds true. Independence cannot be done in a tower of babel, when you have a monolith the overhead is very high for everyone - so everyone is burdened. It is much better to represent decoupled projects as decoupled small VCS systems to manage. If you remember far enough, some companies were using ClearCase and other VCS to manage ALL the company code - the overhead was horrible.
Evgeny Zislis
CC BY-SA 3.0
2017-03-05T08:16:37.513Z
Yup, been there. Exactly that's the reason for which I stick with a branch symbolic representation. If a method can be applied to a monolith it can be applied to the set of broken monolith pieces equally well, if not better. In  some cases replacing or re-organizing the VCS is not an option, for whatever reason. Yet improvement is still possible.
Dan Cornilescu
CC BY-SA 3.0
2017-03-04T03:44:15.783Z
2018-04-12T17:14:06.070Z
2018-04-12T17:14:06.070Z
Dan Cornilescu
<p><strong>What is the MMM</strong></p>

<p>First I want to explain the context for Brook's Law. What was the assumption that made him create it back in 1975?</p>

<blockquote>
  <p>A Man-month is a hypothetical unit of work representing the work done by one person in one month; Brooks' law says that it is impossible to measure useful work in man-months.</p>
</blockquote>

<p><sup>source: <a href="https://en.wikipedia.org/wiki/The_Mythical_Man-Month" rel="noreferrer">https://en.wikipedia.org/wiki/The_Mythical_Man-Month</a></sup></p>

<p>Back in the day, complex programming projects would mean big monolith systems. And Brooks claims that these cannot be perfectly partitioned into discrete tasks that can be worked on without communication between developers and without establishing a set of complex interrelationships between tasks and the people performing them.</p>

<p>This is very much true in highly cohesive software monoliths. No matter how much decoupling is done, still the big monolith mandates time required for the new programmers to learn about the monolith. And increased communication overhead which will consume an ever increasing quantity of the time available.</p>

<p>But does it really have to be this way? Do we have to write monoliths and keep communication channels to <code>n(n − 1) / 2</code> where <code>n</code> is the number of developers?</p>

<p>We know there are companies where thousands of developers are working on big projects ... and it does work. So there must be something that changed since 1975.</p>

<hr>

<p><strong>Possibility to mitigate the MMM</strong></p>

<p>In 2015, PuppetLabs and IT Revolution published the results of the <a href="https://puppet.com/resources/whitepaper/2015-state-devops-report" rel="noreferrer">2015 State of DevOps Report</a>. In that report, they focussed on the distinction between high performing organizations vs. non-high performing.</p>

<p>The high-performing organizations show some unexpected properties. For example, they have the best project due-date performance in development. Best operational stability and reliability in operations. As well as the best security and compliance track record.</p>

<p>One of the surprising things highlighted in the report is the deployments per day metric. But not just deployments per day, they also measured deploy/day/developer and what is the effect of adding more developers in high-performing organizations vs. non-high performing.</p>

<p>This is the graph from that report -</p>

<p><a href="https://i.sstatic.net/6B9ta.png" rel="noreferrer"><img src="https://i.sstatic.net/6B9ta.png" alt="Deployments per Day per Developer"></a></p>

<p>While low-performing organizations align with Mythical Man Month assumptions. The high-performing organizations can scale the number of deploy/day/dev linearly with the number of developers.</p>

<p>An excellent presentation at <a href="https://vimeo.com/165186982" rel="noreferrer">DevOpsDays London 2016</a> by Gene Kim talks about these findings.</p>

<hr>

<p><strong>How to do it</strong></p>

<p>First, how to become a high-performing organization? There are a couple of books that talk about this, not enough space in this answer so I'll just link to them.</p>

<ul>
<li><a href="http://rads.stackoverflow.com/amzn/click/B0058DRUV6" rel="noreferrer">Good to Great: Why Some Companies Make the Leap...And Others Don't</a> by Jim Collins</li>
<li><a href="http://rads.stackoverflow.com/amzn/click/B003GIPEC2" rel="noreferrer">The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition</a> by Steven Spear</li>
<li><a href="http://rads.stackoverflow.com/amzn/click/B004ZK8RTM" rel="noreferrer">The New Economics for Industry, Government, Education</a> by W. Edwards Deming</li>
</ul>

<p>For software and IT organizations, one of the critical factors for becoming a high-performing organization is: <strong>focus on quality and speed</strong>.</p>

<p>For example Ward Cunningham <a href="http://wiki.c2.com/?WardExplainsDebtMetaphor" rel="noreferrer">explains Technical Debt</a> as all the things we allowed to be left unfixed. This is accepted by management because it always comes with a promise that it is going to be fixed when there is time.</p>

<p>There is never enough time, and technical debt just becomes worse and worse.</p>

<p>What are these things that cause technical debt to grow?</p>

<ul>
<li>legacy code</li>
<li>manual configuration of environments</li>
<li>manual testing</li>
<li>manual deployments</li>
</ul>

<p>Legacy code As defined in <a href="http://rads.stackoverflow.com/amzn/click/0131177052" rel="noreferrer">Working Effectively with Legacy Code</a> by Michael Feathers is any code that doesn't have automated testing.</p>

<p>Any time shortcuts are used to get the code to production; the operations is burdened with the maintenance of this debt forever. Then the process of deployment becomes longer and longer.</p>

<p>Gene tells a story in his presentation about a company who has six-week long deployments. Involving tens of thousands of extremely error prone tedious steps, tying up 400 people, and they would do this four times every year.</p>

<p>One of the tenets of DevOps is that reliability comes from doing smaller deployments more frequently.</p>

<hr>

<p><strong>Example</strong></p>

<ul>
<li><a href="https://www.youtube.com/watch?v=dxk8b9rSKOo" rel="noreferrer">Jon Jenkins at Velocity 2011</a>: Amazon are doing <strong>15k deploys/day</strong></li>
<li><a href="https://www.youtube.com/watch?v=YCrhemssYuI" rel="noreferrer">Ken Exner at AWS Summit 2015</a>: Amazon are doing <strong>136k deploys/day</strong></li>
</ul>

<p>These two presentations show all the things that Amazon did to decrease the time it takes them to deploy code to production.</p>

<p>According to Gene, the only thing that is changed across time in these high-performing organizations is the number of developers. So from the Amazon example, you could say that in four years they increased their deployments ten times just by adding more people.</p>

<hr>

<p>This means that under certain conditions, with the right architecture, the right technical practices, the right cultural norms, developer productivity <strong>can</strong> scale as the number of developers is increased. And DevOps is definitely in the middle of all this.</p>

CC BY-SA 3.0
2017-03-03T05:30:35.320Z
2017-03-04T10:14:11.500Z
2017-03-04T10:14:11.500Z
Evgeny Zislis
<p><strong>Brooks's law:</strong> <em>Adding manpower to a late software project makes it later.</em></p>

<p>In his book <em>No Silver Bullet — Essence and Accidents of Software Engineering</em> Frederick Brooks defines the concept of <a href="https://en.wikipedia.org/wiki/The_Mythical_Man-Month" rel="noreferrer">Mythical Man Month</a>:</p>

<p>Brooks's assumption is that complex programming projects <em>cannot be perfectly partitioned into discrete tasks</em> that can be worked on without <em>communication between the workers</em> and without establishing a set of <em>complex interrelationships between tasks and the workers performing them</em>.</p>

<p>Since 1982 we have certainly moved forward and gathered some more experience in mitigating this problem. What are some of the solutions that you have successfully applied at your work to add resources to a project without creating more problems.</p>

CC BY-SA 3.0
2017-03-03T03:11:52.597Z
I'm voting to close this question as off-topic because it fits better in Software Engg. SE (http://softwareengineering.stackexchange.com/), and also cause it's not strictly Devops-specific
Dawny33
CC BY-SA 3.0
2017-03-03T03:14:31.440Z
This is a strictly DevOps specific question. It relates directly to process around software delivery. Are you sure you actually understand what DevOps means?
Jiri Klouda
CC BY-SA 3.0
2017-03-03T03:21:53.397Z
I see it more as a software dev. philosophy rather than strictly Devops  [It's more about project delivery which isn't solely devops specific]. So, I think it'd be much more useful in that SE than here.  :)
Dawny33
CC BY-SA 3.0
2017-03-03T03:22:50.803Z
You keep saying DevOps, I don't think it means what you think it means.
Jiri Klouda
CC BY-SA 3.0
2017-03-03T03:59:34.853Z
I believe the question needs to add a reference that mentions some of the companies who have successfully mitigated MMM. For example organizations like Amazon, Netflix, and Google. Companies who have been able to scale and develop the productivity linearly with the number of developers. Breaking the myth that double the number of developers leads to double the testing effort, the integration effort, and ultimately the deployment effort to get it in the hands of the customers.
Evgeny Zislis
CC BY-SA 3.0
2017-03-03T04:05:55.480Z
Actually I don't know any companies that have successful programs to do this. I was hoping to find out from people who do know in answers.
Jiri Klouda
CC BY-SA 3.0
2017-03-03T04:10:08.407Z
@Dawny33 : Please, read one of the foundational books of DevOps - The Phoenix Project. You will not find a single mention of AWS, Docker, Jenkins,  or any other tools. The entire book is about process, organizational hierarchy and structure, the way to work in teams. DevOps is a way to bring the scientific ideas that improved manufacturing in Japan and later United States to the process of Software Development. Ideas based on work of Edward W. Deming and Eliyahu M. Goldratt. What you see as DevOps is just the surface, the tools, the results. The superfluous parts of it.
Jiri Klouda
CC BY-SA 3.0
2017-03-03T05:12:01.710Z
@JiriKlouda Sure. Thank you for recommending :)
Dawny33
CC BY-SA 3.0
2017-03-03T06:20:17.963Z
related post - from the definition phase: http://devops.stackexchange.com/questions/265/how-can-continuous-integration-scale-for-very-large-projects-teams
Dan Cornilescu
CC BY-SA 3.0
2017-03-03T09:04:20.510Z
@DanCornilescu as related as any other question on devops.stackexchange
Evgeny Zislis
CC BY-SA 3.0
2017-03-03T13:29:56.537Z
@Dawny33 This question is not suitable for Software Engineering. Although this general topic is, the question is far too broad. It is seeking opinions rather than attempting to solve a problem. Please do not suggest other communities if you do not understand what types of questions they accept. If this question were to be posted on Software Engineering, it would be down voted, closed, and likely deleted very quickly. That leads to a poor user experience.
Thomas Owens
CC BY-SA 3.0
2017-03-03T17:44:15.837Z
I don't like the edit, it turn it into beggin a 'those companies are aware of the mythological part of MMM and avoid it'
Tensibai
CC BY-SA 3.0
2017-03-03T20:40:21.817Z
Voting to reopen. Although I still believe this particular question is poorly formed, I believe others with a similar albeit real-world inquiry will benefit from Evgeny's answer below.
Woodland
CC BY-SA 3.0
2017-03-04T05:19:58.127Z
I have removed the paragraph about the companies, as that is really not relevant. It talks about large projects and there can indeed be large projects. Mythical Man Month specifically talks about adding resources to a project and the effect on deadlines and the fact that the progress on a project can slow down shortly after adding people.
Jiri Klouda
<project-management><process><software-engineering>
What are ways to mitigate the effects of Mythical Man Month?
Jiri Klouda
# What are ways to mitigate the effects of Mythical Man Month?

(Asked by: username_0 on 2017-03-03)

**Brooks's law:** *Adding manpower to a late software project makes it later.*

In his book *No Silver Bullet — Essence and Accidents of Software Engineering* Frederick Brooks defines the concept of [Mythical Man Month](https://en.wikipedia.org/wiki/The_Mythical_Man-Month):

Brooks's assumption is that complex programming projects *cannot be perfectly partitioned into discrete tasks* that can be worked on without *communication between the workers* and without establishing a set of *complex interrelationships between tasks and the workers performing them*.

Since 1982 we have certainly moved forward and gathered some more experience in mitigating this problem. What are some of the solutions that you have successfully applied at your work to add resources to a project without creating more problems.

**Tags:** project-management, process, software-engineering

> **Comments:**
> **username_1**: I'm voting to close this question as off-topic because it fits better in Software Engg. SE (http://softwareengineering.stackexchange.com/), and also cause it's not strictly Devops-specific  
> **username_0**: This is a strictly DevOps specific question. It relates directly to process around software delivery. Are you sure you actually understand what DevOps means?  
> **username_1**: I see it more as a software dev. philosophy rather than strictly Devops  [It's more about project delivery which isn't solely devops specific]. So, I think it'd be much more useful in that SE than here.  :)  
> **username_0**: You keep saying DevOps, I don't think it means what you think it means.  
> **username_2**: I believe the question needs to add a reference that mentions some of the companies who have successfully mitigated MMM. For example organizations like Amazon, Netflix, and Google. Companies who have been able to scale and develop the productivity linearly with the number of developers. Breaking the myth that double the number of developers leads to double the testing effort, the integration effort, and ultimately the deployment effort to get it in the hands of the customers.  
> **username_0**: Actually I don't know any companies that have successful programs to do this. I was hoping to find out from people who do know in answers.  
> **username_0**: @username_1 : Please, read one of the foundational books of DevOps - The Phoenix Project. You will not find a single mention of AWS, Docker, Jenkins,  or any other tools. The entire book is about process, organizational hierarchy and structure, the way to work in teams. DevOps is a way to bring the scientific ideas that improved manufacturing in Japan and later United States to the process of Software Development. Ideas based on work of Edward W. Deming and Eliyahu M. Goldratt. What you see as DevOps is just the surface, the tools, the results. The superfluous parts of it.  
> **username_1**: @JiriKlouda Sure. Thank you for recommending :)  
> **username_3**: related post - from the definition phase: http://devops.stackexchange.com/questions/265/how-can-continuous-integration-scale-for-very-large-projects-teams  
> **username_2**: @DanCornilescu as related as any other question on devops.stackexchange  
> **username_4**: @username_1 This question is not suitable for Software Engineering. Although this general topic is, the question is far too broad. It is seeking opinions rather than attempting to solve a problem. Please do not suggest other communities if you do not understand what types of questions they accept. If this question were to be posted on Software Engineering, it would be down voted, closed, and likely deleted very quickly. That leads to a poor user experience.  
> **username_5**: I don't like the edit, it turn it into beggin a 'those companies are aware of the mythological part of MMM and avoid it'  
> **username_6**: Voting to reopen. Although I still believe this particular question is poorly formed, I believe others with a similar albeit real-world inquiry will benefit from Evgeny's answer below.  
> **username_0**: I have removed the paragraph about the companies, as that is really not relevant. It talks about large projects and there can indeed be large projects. Mythical Man Month specifically talks about adding resources to a project and the effect on deadlines and the fact that the progress on a project can slow down shortly after adding people.  

---

## 3 answers

### Answer by username_2 on 2017-03-03. Score: 19 | Accepted answer

**What is the MMM**

First I want to explain the context for Brook's Law. What was the assumption that made him create it back in 1975?

> A Man-month is a hypothetical unit of work representing the work done by one person in one month; Brooks' law says that it is impossible to measure useful work in man-months.

source: <https://en.wikipedia.org/wiki/The_Mythical_Man-Month>

Back in the day, complex programming projects would mean big monolith systems. And Brooks claims that these cannot be perfectly partitioned into discrete tasks that can be worked on without communication between developers and without establishing a set of complex interrelationships between tasks and the people performing them.

This is very much true in highly cohesive software monoliths. No matter how much decoupling is done, still the big monolith mandates time required for the new programmers to learn about the monolith. And increased communication overhead which will consume an ever increasing quantity of the time available.

But does it really have to be this way? Do we have to write monoliths and keep communication channels to `n(n − 1) / 2` where `n` is the number of developers?

We know there are companies where thousands of developers are working on big projects ... and it does work. So there must be something that changed since 1975.

---

**Possibility to mitigate the MMM**

In 2015, PuppetLabs and IT Revolution published the results of the [2015 State of DevOps Report](https://puppet.com/resources/whitepaper/2015-state-devops-report). In that report, they focussed on the distinction between high performing organizations vs. non-high performing.

The high-performing organizations show some unexpected properties. For example, they have the best project due-date performance in development. Best operational stability and reliability in operations. As well as the best security and compliance track record.

One of the surprising things highlighted in the report is the deployments per day metric. But not just deployments per day, they also measured deploy/day/developer and what is the effect of adding more developers in high-performing organizations vs. non-high performing.

This is the graph from that report -

[![Deployments per Day per Developer](https://i.sstatic.net/6B9ta.png)](https://i.sstatic.net/6B9ta.png)

While low-performing organizations align with Mythical Man Month assumptions. The high-performing organizations can scale the number of deploy/day/dev linearly with the number of developers.

An excellent presentation at [DevOpsDays London 2016](https://vimeo.com/165186982) by Gene Kim talks about these findings.

---

**How to do it**

First, how to become a high-performing organization? There are a couple of books that talk about this, not enough space in this answer so I'll just link to them.

* [Good to Great: Why Some Companies Make the Leap...And Others Don't](http://rads.stackoverflow.com/amzn/click/B0058DRUV6) by Jim Collins
* [The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition](http://rads.stackoverflow.com/amzn/click/B003GIPEC2) by Steven Spear
* [The New Economics for Industry, Government, Education](http://rads.stackoverflow.com/amzn/click/B004ZK8RTM) by W. Edwards Deming

For software and IT organizations, one of the critical factors for becoming a high-performing organization is: **focus on quality and speed**.

For example Ward Cunningham [explains Technical Debt](http://wiki.c2.com/?WardExplainsDebtMetaphor) as all the things we allowed to be left unfixed. This is accepted by management because it always comes with a promise that it is going to be fixed when there is time.

There is never enough time, and technical debt just becomes worse and worse.

What are these things that cause technical debt to grow?

* legacy code
* manual configuration of environments
* manual testing
* manual deployments

Legacy code As defined in [Working Effectively with Legacy Code](http://rads.stackoverflow.com/amzn/click/0131177052) by Michael Feathers is any code that doesn't have automated testing.

Any time shortcuts are used to get the code to production; the operations is burdened with the maintenance of this debt forever. Then the process of deployment becomes longer and longer.

Gene tells a story in his presentation about a company who has six-week long deployments. Involving tens of thousands of extremely error prone tedious steps, tying up 400 people, and they would do this four times every year.

One of the tenets of DevOps is that reliability comes from doing smaller deployments more frequently.

---

**Example**

* [Jon Jenkins at Velocity 2011](https://www.youtube.com/watch?v=dxk8b9rSKOo): Amazon are doing **15k deploys/day**
* [Ken Exner at AWS Summit 2015](https://www.youtube.com/watch?v=YCrhemssYuI): Amazon are doing **136k deploys/day**

These two presentations show all the things that Amazon did to decrease the time it takes them to deploy code to production.

According to Gene, the only thing that is changed across time in these high-performing organizations is the number of developers. So from the Amazon example, you could say that in four years they increased their deployments ten times just by adding more people.

---

This means that under certain conditions, with the right architecture, the right technical practices, the right cultural norms, developer productivity **can** scale as the number of developers is increased. And DevOps is definitely in the middle of all this.


---

### Answer by username_5 on 2017-03-03. Score: 5

What I have done (and this is only subjective) is as follows:

When a manager thinking about a due date wishes to add people into my team to cut the time needed and seems under MMM, I first discuss with him or her on why this could be bad. My favorite analogy for this is to remind them that if one woman can have a baby in nine months, nine women won't have one baby in one month, but they'll have nine babies in nine months. The time isn't cut, just the parallel processing is better.

When the decision is forced upon our team, we usually try to either further divide some tasks, and when this is not possible we usually rely on [pair programming](https://en.wikipedia.org/wiki/Pair_programming), where one programmer is responsible for typing, and the other dictates the code (and switching periodically).

The code writing itself is slower, but there's fewer typo/linting and bugs when testing because of the inevitable review done while writing. I feel the overall code quality is also a little better, but I've no metrics to support that claim.

> **Comments:**
> **username_0**: I like the pair programming idea. That is actually something that could help. I might be able to explain why later based on the theory I have been working on.  
> **username_7**: please do, waiting for it!  

---

### Answer by username_3 on 2017-03-04. Score: 4

Speaking exclusively from a CI perspective, increasing the number of developers working on a project typically translates into more people working in the same branch.

Traditional CI systems have a scalability issue in this respect: the probability of breakages/regressions/blockages increases slowing down the integration speed and inviting smaller teams to break off and move on to child branches (i.e. further slowdowns). See [How can continuous integration scale for very large projects/teams?](https://devops.stackexchange.com/questions/265/how-can-continuous-integration-scale-for-very-large-projects-teams). This plays right along the Mythical Man Month concept.

The solution I suggest in my answer to that question, a *highly scalable* CI system would enable migration towards true CI - single branch/trunk based integration for entire greater teams (even with huge sizes).

With everyone of the same page, using the same automated tools/processes and the vast majority of the QA verifications automated inside the CI system itself it becomes much easier to switch roles and focus between team members. The whole development proces becomes smoother, more predictable, more relaxed.

Bringing new people aboard in such an environment, getting them productive simply by offloading less difficult tasks from the more experienced team members which can then take on more difficult ones is thus easier.

All of these can be seen, I believe, as soothing the Mythical Man Month concept effects.

> **Comments:**
> **username_2**: In high-performing organisations, adding more developers usually means creating more independent teams who write decoupled software. This allows more people to achieve more and faster. Having them all communicate via a single integration branch is an anti-pattern and most probably will slow things down considerably.  
> **username_3**: `Having them all communicate via a single integration branch is an anti-pattern` - why? If they're decoupled in the sense that they will no longer need to integrate their work then they will touch the branch in a non-overlapping/non-conflicting manner. If their work still needs to be integrated then going on additional branches will just delay and complicate the integration by deviating from the CI methodology and losing all its advantages.  
> **username_2**: I think we are not agreeing on the meaning of "branch". It is fine to have one large repository, with a single branch (git, or svn), and suffer the overhead of everyone working on the same one. It is also fine to have multiple repositories where each repository has a branch that tracks that specific decoupled service. It depends on the tool, the amount of overhead it adds to commit and checkout code.  
> **username_3**: Ah, sorry, yes - I'm so used to it and keep forgetting others aren't. By branch I'm referring to the high-level, generic representation of the SCM branch, it doesn't really matter which are the particularities of the actual underlying SCM system(s) as long as they're managed together in a monolithic manner. 1 big repo with a `main` branch or 10 side-by-side repos (git modules?) each with a `main` branch should be pretty much equivalent from the CI prospective.  
> **username_2**: Then my statement from the first comment holds true. Independence cannot be done in a tower of babel, when you have a monolith the overhead is very high for everyone - so everyone is burdened. It is much better to represent decoupled projects as decoupled small VCS systems to manage. If you remember far enough, some companies were using ClearCase and other VCS to manage ALL the company code - the overhead was horrible.  
> **username_3**: Yup, been there. Exactly that's the reason for which I stick with a branch symbolic representation. If a method can be applied to a monolith it can be applied to the set of broken monolith pieces equally well, if not better. In  some cases replacing or re-organizing the VCS is not an option, for whatever reason. Yet improvement is still possible.  
> **username_2**: It is a common illusion that a system can be improved by improving each part it is comprised of. When you study system thinking, or the holistic approach to systems, you learn very quickly that it is not true. Improving every part in a system, usually makes the whole system worse not better.  

---

