A Philosophy of Software Design

The central argument

Ousterhout argues that the main difficulty in software is complexity, which he defines by its symptoms: changes that ripple across many places, a high cognitive load before you can make a change, and unknown unknowns where it is not obvious what you need to know. Complexity builds up gradually, through many small decisions, rather than one bad one.

His main defence is the deep module: a module whose interface is simple compared with the functionality it hides. A shallow module, with an interface nearly as complicated as its implementation, adds cost without paying it back. Much of the book applies this lens to classes, methods, error handling and layers.

Ideas you will keep using

• Information hiding and leakage: when two modules share knowledge of the same design decision, changes spread.
• Different layer, different abstraction: pass-through methods and variables are a warning sign.
• Pull complexity downwards: it is better for a module's implementer to suffer than every caller.
• Define errors out of existence: design APIs so that fewer special cases exist to handle.
• Design it twice: sketch at least two alternatives before committing.
• Strategic versus tactical programming: invest a little continuously in design instead of only shipping the next feature.

Where it argues with the consensus

It makes a direct case against splitting code into very small functions, because every extra function adds an interface to learn. It also argues that comments are essential, since much design knowledge cannot be expressed in code, and gives specific guidance on what a good comment says. The second edition (2021) adds a chapter on deciding what matters, expands the chapter on general-purpose modules, and includes explicit comparisons with Robert Martin's Clean Code on method length and comments. Reading both books is a good way to form your own view.

How to read it

It is short enough for a weekend. Read it once straight through, then keep a list of the red flags it names (shallow module, information leakage, pass-through method, vague names, comments that repeat the code). For the next few weeks, look for them in code reviews and in your own pull requests. The book lands best if you have maintained code for a while; as a first-year student, much of it will feel abstract.

What readers say

On Goodreads it averages 4.22 out of 5 from about 4,900 ratings (September 2026). Reviewers there consistently praise its brevity, the deep versus shallow module idea and the strategic versus tactical programming distinction, and many say the first half on abstraction and interfaces is the strongest. Common criticisms are that the second half is weaker, that the long treatment of comments feels disproportionate, that it is quite object-oriented and academic in outlook, that examples are simple, and that it is sceptical of test-driven development in a way some readers disagree with.

Common questions

First or second edition? Get the second (2021). If you already own the first, the author's site offers an extract with the new chapters and the Clean Code comparison.

How long does it take? A weekend for a first read. Re-reading the red flags list occasionally is where the lasting value comes from.

Is it better than Clean Code? They answer different questions and disagree in places. Clean Code focuses on code-level habits; this book focuses on module and interface design. Many engineers find this one more useful once they have maintained a real codebase.

Best for: developers with a year or more of real project work who want a principled way to judge design, especially those who learned from Clean Code and want the counter-argument.