40-Year-Old Lessons and the Mythical Man-Month
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.
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!
We're always looking for talented Project Managers. If you're looking for a job, take a look at our jobs section.
Get in touch to talk about your project
We like to meet. Early on. It’s the best way to work out whether we are a fit.
De-risk your project
We can remove the barriers to getting your project going. Ask us how we do this.
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.