The Mythical Man-Month, 50 years later

The whiteboard had eight names on it. Eight engineers, added in two sprints, because we were behind and the product manager had done the math: eight heads working in parallel would close the gap. I was the one who agreed to it. I stood at the front of the room and said yes, this will help, we can onboard them fast.

Three weeks later we had sixteen people in the daily standup. The meeting had grown from fifteen minutes to forty. Two of the new engineers had introduced a subtle race condition that nobody caught for nine days. One of the original engineers had quietly started working nights to re-explain the architecture to newcomers, which meant she was no longer building. We shipped three weeks later than before I added the eight people.

I did not know, at the time, that Fred Brooks had described this outcome in 1975. That the whole tragicomedy had a name. That someone had already written the book.

Brooks’ Law, and why it still stings

The Mythical Man-Month was published in 1975, drawn from Fred Brooks’ experience managing the development of OS/360 at IBM. It is not a long book. It is also not a gentle one.

The central observation — since named Brooks’ Law — is simple: adding manpower to a late software project makes it later. The reasoning is what matters. Every new person you add to a team doesn’t just add capacity. They add communication paths. Two engineers have one channel between them. Five have ten. Fifteen have one hundred and five. The number of channels grows as n(n−1)/2, and each channel requires attention, synchronization, and repair when it breaks down.

Brooks wasn’t saying large teams can’t build software. He was saying that software is made of communication, and communication does not scale linearly with headcount. Training a new engineer, onboarding them to the codebase, catching the mistakes they make while they’re finding their footing — that cost falls on the people who were already there. The people who were already behind.

I had eight people with velocity. I added eight more and got sixteen people with a communication overhead that ate the velocity I was trying to protect.

This is not a subtle failure mode. It’s written down. It has been written down for fifty years.

Second-system syndrome, and the rewrite that was going to fix everything

There’s a chapter in The Mythical Man-Month called “The Second-System Effect.” Brooks describes the pattern: an engineer builds a first system under pressure, with constraints, making pragmatic cuts. It works. They’re now experienced. They know exactly what they’d do differently. Given the chance to build the second version — unconstrained, with their hard-won knowledge — they over-engineer it spectacularly.

The second system is always the most dangerous. It is the one where experience becomes arrogance and architectural elegance crowds out ship dates.

I have seen this in every organization I’ve worked in. Not always a full rewrite — sometimes it’s just a component. The payment module that “needs to be rebuilt from scratch.” The authentication service that the previous system got wrong, so this time we’re going to build it properly, with full extensibility, supporting every OAuth provider you could name, abstracted to the point where adding a new provider requires three interface implementations and a factory method. Shipping it takes eight months. It serves one provider.

Brooks named this. In 1975. It hasn’t stopped happening.

”No Silver Bullet” — the essay that ages better than the book

In 1986, Brooks published an essay titled “No Silver Bullet — Essence and Accidents of Software Engineering”. It was included in the Silver Anniversary edition of The Mythical Man-Month in 1995 as “No Silver Bullet — Refired,” with a follow-up response to his critics. I think the essay is arguably more important than the original book.

The argument: software development has two kinds of difficulty. Accidental complexity — the friction introduced by our tools, our languages, our environments — and essential complexity — the irreducible difficulty of the problem itself. Over the decades, we have largely solved accidental complexity. High-level languages. Garbage collection. IDEs. Version control. Cloud deployment. Each of these removed friction that didn’t have to exist.

But essential complexity doesn’t yield to tooling. Figuring out what a system should actually do, managing the interactions between components, reasoning about edge cases and failure modes and user behavior — that’s the hard part. And no tool, no matter how powerful, removes it. There is no silver bullet.

Brooks was writing in response to AI optimism. The specific technologies he was responding to were expert systems and automated programming tools. Fifty years later, the optimism has a different shape. But the structure of the argument is unchanged.

What changes when one of your team members is an LLM

Here is where I have to be honest, rather than just citing a dead man’s authority.

Brooks’ communication-cost argument assumed human teammates. Every person added to a team costs onboarding time, requires explanation, introduces coordination overhead. But an LLM is not a person. It does not need to attend the standup. It does not misunderstand the architecture and introduce a race condition out of confusion. You do not have to explain the domain to it repeatedly while it finds its footing.

So is adding an AI tool to a late project a silver bullet?

No. But the reason is more interesting than “Brooks said so.”

The communication cost is different, not zero. When I add an LLM to my workflow, I spend time learning to prompt it well, learning where it hallucinates, learning which of its outputs to trust and which to verify. That onboarding cost is real. It’s just much lower than a human’s, and it doesn’t scale with team size — I pay it once, not n times.

What an LLM cannot do is reduce essential complexity. It can scaffold the boilerplate. It can suggest implementations. It can speed up the parts of the work that were already solvable. But deciding what the system should do, catching the design decision that will create six months of technical debt, knowing which trade-off is worth making this sprint — that’s still human work. The AI doesn’t make the hard parts easier. It makes the easy parts faster, which is useful, but it is not the breakthrough the optimism implies.

Adding an AI tool to a late project is not a silver bullet. It is not a new mythical man. It is a team member with unusually low onboarding cost, high output on well-defined tasks, and no judgment whatsoever. Budget for that honestly and it pays off. Treat it as a shortcut to the essential complexity and you’ll be back at the whiteboard, adding names.

The one thing that aged awkwardly

Brooks devotes a chapter to the “surgical team” model, borrowed from Harlan Mills. The idea: one chief programmer — the surgeon — does all the critical intellectual work, supported by specialists whose job is to shield them from everything that isn’t thinking. A small, hierarchical team where the best person does the best work and everyone else creates the conditions for it.

In 1975, this was a serious organizational proposal. By 2026, it describes almost no software team that exists.

Modern software development is collaborative in a way the surgical team model doesn’t accommodate. Design is shared. Code review distributes knowledge and catches errors the surgeon would miss. On-call rotations assume that more than one person understands any given system. The best teams I’ve worked on have not had surgeons. They’ve had strong engineers who could each hold significant complexity, challenged by equally strong colleagues. The intellectual hierarchy that makes the surgical team model work is a constraint most healthy teams actively work against.

Brooks was prescribing something real — concentrate your best people on your hardest problems, protect them from overhead. That instinct is still right. But the metaphor froze the solution into an org chart that the industry largely abandoned, and for good reasons.

What the book is actually about

I’ve been describing The Mythical Man-Month as a project management book. It is not, quite.

The project management advice is specific and sometimes dated. The organizational chapter is a product of its era. The estimates and heuristics reflect a world where “write a module” meant something much more laborious than it does today.

What the book is actually about is the impossibility of shortcuts in work that is made of communication. Software isn’t hard because the computers are slow or the languages are difficult or the tools are bad. It’s hard because it is a sustained act of translation — between what users need and what engineers build, between the specification and the implementation, between what one engineer understands and what their teammates do. Every shortcut that ignores that translation cost accumulates interest.

Brooks won the ACM Turing Award in 1999 — not for The Mythical Man-Month but for his earlier contributions to computer architecture. He died in 2022 at 83. The project management community did not give him an award. They gave him something better: fifty years of project managers reading this book, recognizing their own mistakes in it, and still making them anyway.

That gap — between knowing and doing — is what the book is really documenting.

The whiteboard, re-read

I think about that whiteboard sometimes. Eight names. Added in confidence.

If I’d read the book before that meeting, I’m not certain I would have decided differently. The pressure was real. The deadline was real. The product manager’s math was seductive — eight more engineers, problem solved — and I was the person whose job it was to be optimistic in public.

But I would have known, walking into that room, that I was making a risky bet rather than a sensible plan. I would have calculated the communication cost before I agreed to it. I would have had a word for what I was about to do: Brooks’ Law. And I would have had fifty years of evidence that the word existed for a reason.

That’s what a good book does. It doesn’t stop you from making the mistake. It makes you make it with your eyes open, which is a different thing entirely.

The whiteboard is still there, in a conference room I rarely use anymore. Somebody painted over the eight names. I still know exactly where they were.

---