That's because only one women can build a baby at a time. Whereas multiple people cann work on an app at the same time and ship it faster than one person.
I have, many many times, seen a large organization "crash" a project, that is to say put a bunch of new developers into it. It almost never works. The first thing that happens is that everything stops, while the existing devs tell the new ones what is going on and what needs to be done.
The second reason it doesn't work is that splitting the app into separate parts that can be worked on in parallel, is essentially determining the software architecture. If you haven't sorted that out then the different parts will get built, not work together, and then there will be a sh*%storm of blaming each other for why they don't work together.
There are cases where new devs can help, but if you don't have the overall architecture sorted out yet, then they will not, and if you do then there is a finite pace at which new devs can be integrated and brought up to speed.
The old analogy to pregnancy is, in fact, spot on.
The point you seem to be missing is that some work is quite simply not parallelizable, which is what people try to convey when talking about multiple women not being able to give birth to a single baby in less than 9 months.
You can staff up bigger teams to accomplish bigger goals, but this is far from linearly scalable, with different categories of problems showing up in larger organisations.
Piling devs onto a project is counterproductive for fundamental communications reasons.
The three chief alternatives are:
- Highly modularise the project and treat those modules as independent projects.
- Launch multiple projects which compete against one another for ultimate launch. Again, treat those as independent projects.
- Buy competing projects. This is a variant of the second option. The competing projects are inherently independent.
Both approaches reduce communications overhead. The result isn't faster production, but rather risk mitigation and diversification over a larger set of investments. Both approaches also work best for an organisation which already has a large engineering capacity.
The second reason it doesn't work is that splitting the app into separate parts that can be worked on in parallel, is essentially determining the software architecture. If you haven't sorted that out then the different parts will get built, not work together, and then there will be a sh*%storm of blaming each other for why they don't work together.
There are cases where new devs can help, but if you don't have the overall architecture sorted out yet, then they will not, and if you do then there is a finite pace at which new devs can be integrated and brought up to speed.
The old analogy to pregnancy is, in fact, spot on.