[m0nastic]

I've actually always disliked this analogy as it relates to project delivery (whether it be software development or a consulting project).

It suggests that there is nothing anyone can do to decrease the amount of time that a baby gestates; but that's quite different from project delivery.

While adding bodies does not necessarily divide the length of time required, there are absolutely concrete things which can be done to reduce the timeframe.

You can reduce scope (or features) for starters. A woman doesn't have the option of delivering a "minimum viable product" of a baby (with only core features) in less than 9 months, but a consulting engagement could certainly cut out features to be completed sooner.

Childbirth is a subset of project delivery whose completion dates are not particularly fungible. There are numerous other types that are.

[michaelpinto]

Part of my career has been doing software project management, and it's been very rare that an end client that I was working for was willing to extend a deadline or limit the functionality of a project. If a company is run and backed by software professionals this may happen, but for most other projects you just aren't allowed to change the rules — which is why the baby analogy holds so true.

[m0nastic]

Right, but here's my problem with that:

I understand that the reason the analogy has become popular is because at some point, an idiot manager looked at a project plan, saw that the project was supposed to take (let's say) 6 months, and said "Hey, if we increase the number of developers from 2 to 6, that means it will only take 2 months."

So I get why it's easy to respond with "9 women can't make a baby in 1 month."

But let's say that instead the project plan said that it was going to take 6 months, and there was 1 developer on the project. It's absolutely likely that adding an additional number of developers can shave some time off that project (not inversely proportional to the number of developers you add, and not in every single circumstance, but I'd argue for the overwhelming majority of projects).

The analogy suggests that no part of project development can be parallelized, which to me just seems like shitty management of the project.

[michaelpinto]

The problem with the 6 months 1 programmer vs 1 month 6 programmers is that the minute you have more than one programmer they have to have an architecture that works together plus take time to communicate with each other — and then add to that the concept of a "critical path" i.e. that one programmer may not be able to start something until another programmer is done.

Although in my professional experience the idea of adding more programmers is always suggested by the client about a week before the project is due!!!

PS If you had to live through about ten of these clients you'd have the same religious feelings that I do for the Mythical Man Month.