I've always like the MMM but there is also an undercurrent of this being a re-telling of xeno's paradox, and its important to remember the rabbit actually does win.

So, adding new bodies does incur cost, but the belief that always adding new bodies always adds more cost than adds impetus to the outcome is not always true.

The classic example is "the hump" which was the cost in fuel terms to ship fuel to China, to be able to fly from China to bomb Japan. Economically ruinous, people forget that missions were nonetheless successfully conducted: it was ruinous but the outcome was achieved within limits.

So the MMM does not say "never add a body" it says "know what your incurring in overhead, choosing to add a body"

I should say that I mis-speak (write) characterising MMM this way, its how its casually talked about. The incremental benefit of adding people can be higher than zero, but less than enough to be worth the cost. It can also be negative which is the core point MMM was making. Can be, is not always. And of course there are problems where it simply cannot alter the trajectory at all (the baby problem)

The difference is that in software, if you add a body and as in most organizations, that body has to appear useful, they will tramp about in the soup, making a big mess and harming progress.

Unlike in war, the marginal curve of adding an extra body goes negative in software. And right quick unless circumstances are favorable.

(If you doubt this, imagine a thousand Arthurs charged with implementing a CRUD app.)

From what I recall, it talks about 3 somewhat related things.

First is that adding people slows things down in the short term.

The second is that due to overhead, adding people won't give linear speed up in completion time.

And third, adding people won't help a project that is linear in nature. The common example is using 9 women to get a baby in 1 month.

That's a good summary.

My years suggest that he wasn't nearly pessimistic enough.

You mean if you add 9 women you get a baby in 81 months?

I mean that in the limit, adding the n+c'th person isn't just useless, it's devastating. If the optimal (in terms of calendar date of completion) size for a project is (say) three people, it is entirely possible, if not almost certain, that putting 30 people on the project will push the expected completion date to infinity. In other words, the project will fail.

Now, you might say, "I will just bench those other 27 people" and have them play cards or something. In most organizations, though, you cannot do this. Instead, they must be seen to be useful somehow. And if you have 30 people with their hands in a three-person project, no matter how peripherally, failure is all but guaranteed.

I have seen this many times.

100% feel you.

Last time I worked at a big company, there was lots of dead wood, but one guy in particular was just a massive liability. Nice guy, tried hard, but utterly incompetent, and (I think there is a term for this?) he was unaware / ignorant of how incompetent he was. He would often check in code that would break the build (team of 300 engineers, large telecom system), he would write and run scripts that would bring computing clusters to their knees (this was late 90s, there are probably ways to mitigate that now), he would consume lots of high-quality talent's time with basic questions, etc.

I literally asked my manager if we could pay Leo to sit home and play video games. OF course, as you said, everyone's gotta look busy.

Here's the punchline: I learned a new term (to me, at the time... not sure I've heard it again) from a greybeard/wizard there -- this guy was a genius. He had a very appropriate term for Leo: negative producer.

Bingo!

Reading this book AND trying to follow its key lessons makes a huge difference in productivity, which I can testify from my own experience. This book is often compared to the bible of software engineering, suggesting that everyone knows about the book (ex: 'no silver bullet'), some people read it, but only few people abide by it. So, its key lessons are hard to follow in the real world, but for a good reason.

We started a project 5 years ago, after a few months of failed attempts. From the very onset of the project, we tried to adhere to the key lessons of the book. Examples are: recognizing the importance of minimizing communication overhead (the most important assets are not people but time), following the surgical model (key decisions should be made by a single individual), practicing effect-free programming whenever possible, allocating enough time for testing, and so on. I would definitely attribute the success of our project to the teachings of the MMM.

Like many books on software engineering (and self-help books in general), just reading a book and learning its contents may not make any difference in practice. Only when you seriously make conscious efforts to practice its teachings do you realize what the book is really about. This is also the reason why many university courses on software engineering are boring.