40-Year-Old Lessons and the Mythical Man-Month

Edd Baldry
Edd Baldry

Project Manager 26 Aug 2015 x min read

In the world of the web it’s sometimes easy to get caught up in bleeding edge conversations about technology and technique. It’s odd to think that one key theory on software development turns 40 this year.

In 1975, Fred Brooks published The Mythical Man-Month, a book to help understand how to undertake complex development projects. It remains as essential today, as when it was first published.

The central premise is a simple statement: A project that requires five team members to work for five months cannot be completed by a twenty-five person team in one month.

It’s a premise that elegantly articulates the fact that effort is not the same as progress. Brooks expanded on the rationale that a project that is late is likely to become later if you add more people to it. This became known as Brooks’s Law.

Scaling stress

The underlying concept behind Brooks’s law is that as a project scales, the communication complexity involved increases. In other words; adding team members isn’t without costs. As Brooks put it himself, ‘When the schedule slips, the first response is to add manpower, like gasoline to a fire’.

Brooks came up with a formula that communication channels are equal to the triangular number equation of n(n-1)/2.


This means that though a small team of six creates 15 links between one another, a larger team of 12 will generate 66 links, and if the team were increased to 50 there would be no less that 1,225 communication links to manage.

His argument follows that an increase in communication channels leads to an increase in complexity, which reduces the team’s productivity and resilience to any problems they encounter.

The law has been challenged, notably from Linus Torvalds, the creator of Linux and Git. He argues that open-source projects offer an observable occasion where Brooks’ law doesn’t hold true. Linux for example has 1,000 kernel contributors, but has consistent growth of 10% per year.

Still, in the day-to-day world of development Brooks’s law has entered into received wisdom. At Amazon, Jeff Bezos, instituted a two pizza rule on any team, if two pizzas couldn’t comfortably feed the team then it was too big. At Spotify, Henrik Kniberg, created the concept of squads, tribes and guilds to create shippable components of the service. At gov.uk, the UK government’s digital service, they’ve adopted team sizes between 5 - 10 to ensure project success.

Change is a feature not a bug

Whilst The Mythical Man-Month is most famous for the eponymous chapter that gave rise Brooks’s law, it also deserves attention for its other chapters.

The two chapters, ‘Plan to throw one away’ and  ‘Hatching a catastrophe’ make Frederick Brooks a good candidate as the godfather to agile development processes.

The language of ‘Plan to throw one away’ is entertainingly retro, with jargon of the 70s technology zeitgeist. Strip it back to the underlying meaning though and it’s not far off from the agile manifesto:

  • Plan to run a pilot and scale from there

  • Change is the only constant

  • Plan the system to accommodate these changes

  • Plan the organisation for these changes

  • Expect to take two steps forward and one step back

(☨Okay, I lied, it is a little way from the agile manifesto, but considering it predates it by 30 years it’s a pretty impressive prototype of an agile development cycle nonetheless)

Meanwhile the opening phrase for his final chapter ‘Hatching a catastrophe’ is: "Question: How does a large software project get to be one year late? Answer: One day at a time!" The chapter is insistent that the only way to meet deadlines was to ensure the project was split into smaller work with regular, small, individual milestones needing to be met.

How Torchbox avoids falling in the tar pit

The Mythical Man-Month opens with Brooks talking about how software projects, like dinosaurs and other animals from prehistory, can easily sink into tar pits, regardless of the skill, strength or speed of the animal. At Torchbox we’re fairly confident that falling in a tar pit is going to end badly, so we’ve worked hard to take on board the lessons that Brooks set out.

We work carefully with each client to discover the needs of their users, and then work internally to ensure that we can come up with realistic estimates. We use a kanban system to track work and ensure the actual velocity matches our estimated progress.  We accept that change is inevitable and ensure regular iterative work is undertaken to ensure any project is always moving in the right direction.

The mythical man month is just that, mythical, and we know that a project can’t be delivered in one month by 25 people when it should take five people five months!

If you haven’t read The Mythical Man-Month it’s available on the Internet Archive. If reading an entire book feels like too much work, here's an entertaining edited version.

We're always looking for talented Project Managers. If you're looking for a job, take a look at our jobs section

Edd Baldry
Edd Baldry

Project Manager 26 Aug 2015 x min read

Get in touch to talk about your project

  • 1


    We like to meet. Early on. It’s the best way to work out whether we are a fit.

  • 2

    De-risk your project

    We can remove the barriers to getting your project going. Ask us how we do this.

  • 3

    Your brief

    If you’ve got a brief, we’d love to see it. If you haven’t, talk to us before you write it, we can help.