A Philosophy of Software Design by John Ousterhout is a short, focused book arguing that software design is fundamentally about managing complexity, and it distills this idea into 21 brief chapters that each take about 10 minutes to read. The reviewer, a software engineer and engineering manager, finds it excellent despite initial skepticism about its brevity.
Who Wrote the Book and How It Was Written
John Ousterhout is a professor at Stanford who teaches a software design class where students work through projects over a semester.
He wrote the book after teaching the class three times, observing what design approaches worked and which didn’t — a rare methodology in software, where you typically design once and ship once without a chance to compare alternatives.
This iterative, observation-based approach to writing the book is unusual and gives the advice an empirical grounding.
What the Reviewer Liked
A fresh definition of software design: The book frames software design as a means to fight complexity. The greatest limitation in writing software is our ability to understand the systems we create; simpler design lets us build larger, more powerful systems before complexity overwhelms us.
A fresh, simple look at architecture: The book avoids complex diagrams and instead offers simple observations that compound into something powerful. The first half introduces ideas like tactical versus strategic programming, deep modules, information hiding and leakage, general-purpose modules, different layers of abstraction, pulling complexity downwards, and the “better together or better apart” principle.
Information hiding and leakage: Ousterhout noticed that students who divided code into small, shallow modules ended up with duplicated business logic caused by information leakage, reinforcing why modules should be deep.
“Design it twice”: A three-page chapter arguing you should design something two different ways and compare trade-offs. The reviewer calls it brilliant and notes that almost no one actually does it, but it works in practice.
What the Reviewer Didn’t Like
The book never discusses the relationship between architecture and testability. The reviewer emailed Ousterhout, who said this was intentional, but the reviewer disagrees — good architecture should account for automated testability.
There is no ebook version and no plans for one, so readers must get a physical copy.
Verdict
The reviewer rates it not just good but great, because it focuses on the essence of software design — reducing complexity — and reduces its own complexity in the process, making it easy to read.
The cover itself reflects this: complexity at the top, simplicity at the bottom.
Recommended for any software engineer who plans and builds systems.
