The Mythical Man-Month

My Thoughts

Few books about software engineering survive changes in programming languages, architectures, platforms, and development methodologies. The Mythical Man-Month is one of them.

First published in 1975, Frederick Brooks’s collection of essays grew out of his experience managing the development of IBM’s OS/360. The technology belongs to another era. The problems do not.

That is precisely why the book remains important.

The Mythical Man-Month examines why large software projects become difficult, why schedules slip, and why simply adding more people rarely solves the problem.

Its most famous idea is Brooks’s Law: adding manpower to a late software project can make it even later. Software work cannot always be divided and parallelized like factory production. New people require onboarding, communication grows rapidly with team size, and some activities are inherently sequential.

I have often summarized the principle with a simple analogy:

“Nine women can’t make a baby in one month.”

That principle has stayed with me because it captures something fundamental about engineering work: capacity and elapsed time are not interchangeable.

Brooks goes well beyond project staffing. He explores conceptual integrity, the importance of a coherent architectural vision, the dangers of the second-system effect, and the difficulty of estimating complex intellectual work.

What makes the book remarkable is how little its central message has aged. Technologies, languages, tools, and methodologies have changed dramatically, but the underlying challenges of software engineering—complexity, communication, coordination, architectural coherence, and disciplined judgment—remain largely the same.

It is not simply a historical software book. It is a book about the fundamental nature of building complex systems with people.

The anniversary edition was published in 1995. I was fortunate to read it the following year, at the beginning of my software engineering career. Nearly three decades later, I found myself returning to it—this time to reconsider Brooks’ principles through the lens of AI-augmented software engineering.

If AI makes implementation faster, the bottleneck moves upward—to architecture, judgment, integration, prioritization, and coordination. Brooks’ principles are not becoming obsolete; they are becoming relevant at a different level of the engineering process.

AI changes the economics of software construction. It does not repeal the laws of software engineering.