In 1975 Fred Brooks published The Mythical Man-Month, a set of essays drawn from managing one of IBM's biggest software projects of the 1960s: the operating system for its System/360 computers. Half a century later the technology is unrecognisable, and the book is still in print. Most of it still holds, because it's about people rather than machines.
If you're thinking of commissioning software, three of its ideas are worth knowing.
Adding people to a late project makes it later
The title pokes fun at an old planning habit. A job estimated at twelve "man-months" was assumed to take one person twelve months, or two people six, or four people three. People and months were treated as interchangeable.
Brooks saw again and again that they aren't. His conclusion became known as Brooks's law: adding manpower to a late software project makes it later. There are two reasons.
- New people need bringing up to speed. Every project has its own decisions, terminology and history. Someone joining late has to learn them, and they learn them from the people already doing the work, who slow down to teach.
- Communication grows faster than the team. Three people have three conversations to keep in step. Ten people have forty-five. Past a certain point, more time goes on coordinating than on building.
Some work simply can't be divided. As Brooks put it, bearing a child takes nine months, however many people are assigned to it.
Conceptual integrity matters most
Brooks argued that the most important quality of a system is that it feels as though one mind designed it. Every part works the same way, uses the same terms and follows the same logic. A system put together by many hands without that shared vision becomes a collection of features that don't quite fit, and it's harder to learn, to use and to change.
That's far easier to achieve with a small team that knows the whole system than with a large one where everyone knows one corner of it.
Beware the second system
Brooks also warned of what he called the second-system effect. Having learned to be careful with their first system, designers tend to pile every idea they held back into the second. The result is bloated, late and over-designed.
We see the same pattern when a system that has served a team for years is replaced. It's tempting to make the new one do everything the old one did, plus everything anyone has ever wished for, all at once. That's how replacement projects stall.
Software is built by people talking to each other, and it's the number of conversations you have to manage.
What it means if you're commissioning software
- Keep the team small and stable. A few people who understand the whole system will usually beat a crowd who each understand part of it. And the people who built it are the best people to look after it.
- When time is tight, cut scope, not corners. If a date really can't move, decide what can wait. Adding people late rarely buys the time back.
- Replace in stages. Get the most important part of the new system working and in use, then build out from there, rather than switching everything over on one big day.
- Talk early and often. Most of what goes wrong in software is a misunderstanding found late. Seeing a working version early is the cheapest way to find one.
None of this is new. Brooks wrote most of it down before many of today's developers were born. It's still the best advice we know for getting software built well, and it's a large part of why we work the way we do.