A few of us are reading (and re-reading) the Mythical Man-Month, one of the classic books on software engineering. Any reader of the book, or simply a seasoned programmer, knows that “adding manpower to a late software project makes it later.”
The essential reason is that the time-cost of allowing the ones who are familiar with a given system to teach those that aren’t familiar, overwhelm the benefits of having more programmers on-hand. And even once everyone is magically “ramped up”, you then fall into the “too many cooks in the kitchen” problem. So, when new additions or change requests are made to a system, there is almost no benefit to adding more engineers to solve the problem.
Even more importantly, you begin to lose energy, passion, and focus as more hands converge on a problem. In the end, more manpower leads to software that’s far more error-prone than if you cut the manpower out of the way.
The only realistic benefit of more programmers is, you can get alot more sheer coding done. Six programmers can certainly type more than two. But, rarely is software late because there was just too much typing to do.