[171243]

Correct me if I am wrong but isn't the central premise of the book that if you take a late project and add more people to the team it takes the project longer???

I've literally never met a manager that practiced this. Is the book still relevant? Not disagreeing, just curious.

[mikekchar]

It's been ages since I read that book, but there is more to it that just the tag line you mention. It is very common to take a plan for work and to say, "This would take 10 people 1 year to developer, but we need it in 1-2 months. So let's put 100 programmers on the team". This is very much more obvious in Enterprise space and government contracting, but you see the reasoning everywhere.

Here's quite a famous example: https://www.statista.com/statistics/272140/employees-of-twit... It shows a graph of the number of employees at Twitter over time. In Jan '08, there are 8. In Jan '09 there are 29. In Jan '10 there are 130. In Jan '11 there are 350. In Dec '13 there are 2712.

Although a lot of that staff are going to be sales and marketing (and probably the growth is justified), the development team is also growing exponentially during that time. The Mythical Man Month would say that probably they are spending a lot more money than they need to to get the growth they needed.

I used to work for a manufacturer of telephony equipment. On one of the products I worked on they had 5000 developers! (A single piece of code!!!). The average amount of code deployed was 1 line of code per day per developer. As much as we can argue that KLOC is a bad measure of productivity, if your average developer is only producing considerably less than 1 KLOC in an entire year, you know you have really, terrible, terrible problems. One of the questions you might want to ask is, if you want to write about 5000 lines of code a day, where is the sweet spot, actually? I think we can agree it's not at 5000 programmers. However, it's often really, really difficult to talk to non-technical management and get them to understand that more programmers does not usually equal more productivity.

I could regale you with literally hundreds more examples, but I think it's sufficient to say that, yes, the Mythical Man Month is still really relevant these days.

[ergothus]

You've never been on a project that was behind and management decided to add resources to it? Impressive!

The book is worthwhile, not just for the central lesson, but WHY (TL;DR: communication overhead between different individuals increase as you add "nodes" - interestingly, you can make analogies to L2 cache expiration problems and others) and also a nice view at IBM of the past. And it was written in an era where there wasn't the need to make every book 300 pages long, so it's generally a lot more meat/page, though hardly perfect.

[sanderjd]

> I've literally never met a manager that practiced this.

Yeah it's a pretty universal idea.

> Is the book still relevant?

Yes, precisely because that idea is so universal. Its advice has been relevant, insightful, and mostly ignored ever since it was written.