John Ousterhout

This book addresses the topic of software design: how to decompose complex software systems into modules (such as classes and methods) that can be implemented relatively independently. The book first introduces the fundamental problem in software design, which is managing complexity. It then discusses philosophical issues about how to approach the software design process and it presents a collection of design principles to apply during software design. The book also introduces a set of red flags that identify design problems. You can apply the ideas in this book to minimize the complexity of large software systems, so that you can write software more quickly and cheaply.

A Philosophy of Software Design

Davood Ghanbarpour

Your job as a developer is not to create code that you can work with easily, but to create code that others can work with easily

Natalie

The book I wish I had read when first began my career in software engineering. Ousterhout makes a compelling, logical case for addressing complexity in software with simple designs augmented with clearly communicated documentation, rather than prioritizing getting something working as fast as possible. A philosophy that may seem like common sense, but an important one that should be regularly reviewed by any dev, no matter what stage in their career.

Linus Torvalds, on the beauty of programming: "It’s still hard to explain what can be so fascinating about beating your head against the wall for three days, not knowing how to solve something the better way, the beautiful way. But once you find that way, it’s the greatest feeling in the world."

John has a unique perspective as both a practitioner and academician, which allows him to understand both practical and theoretical aspects of software development. This book explores interesting approaches to system design and emphasizes the importance of considering the overall health of the system, rather than just focusing on individual parts.

The book provides insights into why complexity tends to arise in software projects, but also offers practical recommendations that can change your mindset. For example, it suggests writing documentation before implementing any code, which helps in understanding the system’s abstraction better.

Suat Karakusoglu

John has a unique perspective as both a practitioner and academician, which allows him to understand both practical and theoretical aspects of software development. This book explores interesting approaches to system design and emphasizes the importance of considering the overall health of the system, rather than just focusing on individual parts.

The book provides insights into why complexity tends to arise in software projects, but also offers practical recommendations that can change your mindset. For example, it suggests writing documentation before implementing any code, which helps in understanding the system’s abstraction better.

Thanks John,

Mustafa Hussain

I learned so many things reading this book; as I had many concepts that I have taken for granted this book reminded me to rethink about them

Nick Gracilla

This book has the makings of a classic in the field. It is a concise read. Ousterhaut asks: how can a problem be solved, with the simplest possible structure? The reading itself embodies principles of quality software design: clean, simple, obvious, with clear interfaces (in the form of problem statements and recapped conclusions). The fundamental challenge of software design is managing complexity; chapters on information leakage, poor naming practices, and unnecessary complexity with error handling are standouts. I found the discussion on an investment mindset (towards good design principles) vs tactical programming mindset (potentially driven by ‘bad’ agile or TDD) particularly thoughtful. Highly recommended, for developers.

Julien Sobczak

Much more insightful than the classic Clean Code.

If Clean Code is about the obvious, A Philosophy of Software Design is about the subtle. This short book goes deeper and is more insightful than its predecessor. Writing clean code is great, but having a clean design is greater, and I would like more developers to read this book instead of the popular one written by Bob Martin.

For many years, the author questioned if software design can be taught, and if design skill is what separates great programmers from average ones. The result was a new course at Stanford, and after three iterations, this book emerged. A Philosophy of Software Design is clearly not the definitive book on the subject. Only a few real-world projects, mostly written in OO languages, are used to illustrate the principles, and there is so much more to cover about good software design. But as an introduction on the subject, the book is excellent, especially for students.

I found many references to this book by researching about the perils of clean code. A function is often more maintainable when the number of lines of code is small but sometimes, a longer function is preferable. A class is often more maintainable when it has a single responsibility but sometimes, making the common case as simple as possible is preferable. The book is filled with many examples like these. The discussions about some principles like "Design it twice" or "General-purpose modules are deeper" are invaluable. If you want to write clean code, you have to think, and this book will help you ask a lot of questions.

If you read the reviews of any book about code design, you will have a lot of divergent opinions. This book is no exception. The best option is thus to read not just one book, but a lot. Make sure to include this one in your reading list.

Thibault ML

John's book is an incredible piece that all developers, junior or senior, should try to read. John has obviously been bit by many design decisions over the years, and was able to come up with different suggestions and advice that help write good quality software that has as few bugs as possible and that remains maintainable over time.

For years now I had been struggling to explain in code reviews or design sessions the reasons why I gave certain recommendations. While I have learned over time to explain my decisions and design suggestions through what they help prevent/avoid or how they enable other developers, too many times still, all I had was an inkling, a feeling, an intuition. Instead, John's book clearly lay out all those things I have learned the hard way, and explains them with ease and simple examples.

This is the very first programming book where I agree with almost everything that is written. I am looking forward to share this book with colleagues.

A Philosophy of Software Design

Reviews

Highlights