Making Software: What Really Works, and Why We Believe It by Andy Oram, Greg Wilson (Editors) — Summary & Review

Here’s a book that doesn’t just hand you another set of rules or hype a shiny new methodology. "Making Software: What Really Works, and Why We Believe It" is a collection of essays from heavy-hitters in software engineering, all wrestling with one stubborn question: which practices in software development hold up under scientific scrutiny, and which ones are just folklore?

Published in 2010, this tome arrived at a moment when the software world was desperate for evidence-based clarity. Instead of blindly following the latest buzz—be it test-driven development, pair programming, or design patterns—this anthology digs into the research, the numbers, and the experiments behind these trends.

The book’s first big move is to stress the importance of empirical research in software. It’s not enough to say "this worked for me" or "everyone does it this way." We need data, controlled studies, and honest skepticism. This isn’t a dry academic lecture; it’s a call to stop treating software development like a mystical art and start treating it like an engineering discipline.

From there, it dives into some juicy debates. Take programmer productivity, for instance. You’ve heard the stories: some developers are ten times more productive than others. But how much of that is myth? The essays challenge that idea, showing how measuring productivity is messy and how context—like the nature of the task or the team environment—matters way more than just raw talent.

Test-driven development (TDD) gets a thorough grilling. The idea of writing tests before code sounds great on paper. But does it actually speed things up or reduce bugs? The book’s contributors sift through studies that show mixed results. Sometimes TDD helps, sometimes it slows things down, and often its success depends on how it’s implemented and the complexity of the project.

Code metrics—the numbers we use to predict where bugs will crop up—don’t get a free pass either. The book points out that while some metrics correlate with defects, they’re not crystal balls. Relying solely on these numbers can mislead teams into chasing the wrong priorities.

Then there’s design patterns, a favorite topic in software circles. Are they truly the secret sauce for better software architecture, or just a fancy vocabulary for common sense? The essays suggest that while design patterns can improve communication and help structure code, their benefits depend heavily on the developers’ understanding and the problem domain.

Pair programming, often touted as a productivity booster, gets a reality check. It turns out that the personalities involved matter a lot. Two developers with clashing styles or poor communication can tank the process, while a well-matched pair might actually produce better code faster.

Finally, the book tackles the myth of proximity. Conventional wisdom says that sitting close to your teammates makes collaboration easier. But the research shows that organizational boundaries—who you report to, who shares goals—can be even more important than physical distance. That’s a useful insight for today’s distributed teams.

What makes this book stand out is its refusal to hand out easy answers. It’s less about "do this" and more about "here’s what the evidence says, and here’s where we still don’t know." It’s a sobering reminder that software development is complicated, messy, and context-dependent. No silver bullets here.

Of course, some of the research is a bit dated now. The software world is a fast mover, and practices have evolved since 2010. Still, the book’s core message—question everything, demand evidence, and understand context—is timeless.

If you’re tired of the latest management fad or the newest "best practice" shoved down your throat, this book offers a refreshing dose of reality. It’s for those who want to think critically about how we build software, not just follow the crowd.