Mythical Man-Month: Essays on Software Engineering

Summary

Published in 1975. I still see the same problems at work. Fred Brooks writes about project management, team communication, and system complexity, not just code.

The book gave me a lot to chew on. Lessons that, surprisingly, still hold up decades later. Below, a few takeaways I jotted down while reading, roughly in the order the book presents them.

Introduction

I read it for the first time in October 2024 (definitely not the last). Had I read it earlier in my career, I doubt I would have gotten as much out of it. You need some scar tissue from real projects to actually feel what Brooks is talking about.

There’s also the writing itself. Humor and passion on nearly every page, which makes a decades old engineering book far more enjoyable than it has any right to be.

The Joy of Building

You can feel that passion from the opening pages. Brooks talks about the joy of programming, the act of building, calls it “the sheer joy of making things,” and it’s obvious how much he loves it. It’s probably what draws me to this field too: taking something from nothing, watching it work, watching someone else use it.

The Mythical Man-Month

The book’s title comes from the “man-month,” a unit for measuring work effort, used to estimate project deadlines and costs. The idea is that a late project gets more people and then it speeds up.

Seems obvious to me that it doesn’t work. What’s unsettling is realizing this used to be a common assumption, and probably still is somewhere.

Every system is different. So is every person, and so is how they interact with each other. Dropping someone new into a project midstream tends to create more problems than it solves, because communication gets harder and misunderstandings pile up fast, faster than the team grows.

A small, well aligned team beats a large disorganized one, pretty much every time. More is not better.

Plan to Throw One Away

Brooks points out that chemical engineers figured out long ago that nothing comes out right the first time. You build a simplified model first, then refine it into the real product. Software engineering, he argues, still hasn’t fully learned that lesson. First versions are barely usable. A lot of the time there’s no option but to scrap everything and start over.

This has gotten better, in my experience. Agile methodologies caught on, and now frequent deliveries and constant feedback are the norm, not the exception. I can’t remember a project I worked on that got thrown away entirely, though I’ve seen a few that deserved it.

One case that stuck with me: a system that took two years to build in AngularJS and, by the time it launched, was already obsolete. Angular 2 had come out in the meantime. That was 2016. The thing is still running in production as of 2024.

The Whole and the Parts

This chapter opens with a provocation: “How does one build a program to work?” It’s about the importance of modules that are easy to debug and test, and how good change control simplifies maintenance down the line.

Reading this in 2024 is almost funny, these practices are just table stakes now. Never worked on a project without version control, Git or otherwise. Have worked without automated tests though, just a QA team testing everything by hand. And I’ve seen the other extreme too: over 90% coverage, maintained entirely by developers, no QA in sight.

No Silver Bullet: Essence and Accident in Software Engineering

Brooks talks about the endless search for a “silver bullet,” something that would fix software engineering problems once and for all. He argues it’s impossible. There’s no single solution to a problem that’s inherently complex. Figuring out exactly what to build is hard enough on its own.

This chase for a magic fix has followed me through my whole career. Smart editors. Copy pasting from Stack Overflow. Miracle frameworks. More recently, AI. They help with productivity. I still think the best solution is the simplest one for the problem in front of you, not the generic problem the framework of the month claims to solve.

There’s no such thing as a silver bullet.

Conclusion

Brooks’s point is that software engineering depends as much on people and process as it does on code. Human and organizational factors need to stay at the center. For me, the book’s biggest lesson is that a project’s success comes far more from good practices, communication, and decisions made well than from any tool or framework.

If you haven’t read The Mythical Man-Month, I recommend it. It’s a 1975 book that still describes the job.