The mythical man month - still an issue

  • 18 November 2022
  • 2 replies

Userlevel 7
Badge +13

Fred Brooks, author of the seminal book, The Mythical Man Month died yesterday. If you don’t know the book, you should go find a copy and read it. It tackled the head-on the idea that throwing more people at a problem that’s behind schedule delays it even more and also ideas around the complex interrelationships between tasks and the people performing them. The book isn’t about product management, but valuable none the less.

Ironically, as my friend @Ian Ames pointed out on LinkedIn, “47 years after it was first published we still have conversations about 'throwing more people at projects’”

Read the book? What have been some ways you’ve applied it to your work?


2 replies

Userlevel 5
Badge +2

I’ve never read the whole book, but I’ve had lots of discussions about the idea over the years (which reminds me that I really should). I think the reason we still talk about it is because it’s not a hard and fast rule.

Two big issues stand out when you’re trying to accelerate a project with people:

  • It’s really hard to add people when they have no previous experience with the team or code base.
  • It’s even harder when your process is “institutional knowledge”.

 To address those issues you can …

  • Avoid building up siloed dev teams. Make sure each team regularly cross-pollinates ideas and processes and has experience across your code base.
  • Document your process and make sure everyone is generally following it all the time until it becomes second nature.
  • Keep small, multi-functional teams together over long periods of time and do everything possible to retain good people. Retaining talent is just as important as retaining users.

With nimble teams and deeply-engrained process it is absolutely possible to divert resources from one area to another to accelerate projects. They will know how to quickly integrate with other teams and understand the fundamentals of the code. The best case scenario is adding small teams and not new people into another team, but both can work.

That said, sometimes you can only do so much in parallel.
There are hard dependencies that can’t be short circuited.
There are domains that lend themselves to very few, highly-experienced people.
And despite your best efforts, some products are just too new (or old) and unfamiliar.

You can evaluate some standard factors to make the call, but a lot of it comes down to instinct and experience within the environment. “Leadership” they call it 😁

Userlevel 7
Badge +13

I read it years ago and just pulled out my old copy and will have to give it a re-read. I suspect many of the foundations and learnings in it still largely apply.

Wikipedia has a good summary on the book’s page about the major ideas presented in the book.

You make some good points on experience and knowledge as factors that I don’t think the book covers (but I’ll have to see when I re-read it).