A Philosophy of Software Design, 2nd Edition

This book is clear, concise, and avoids padding for the sake of page count. This mirrors how the author advocates that software should be designed: minimize complexity, and pursue simplicity. The book lays out many strategies to achieve this goal, while also explaining how one approach reinforces and strengthens another. I found some of the examples to feel a bit academic, yet most do a good job of clarifying the concept being supported. The author has also offered rebuttals for many of the common reasons developers underinvest in software design, which hopefully helps readers confront their internalized self-bargaining techniques (some of which can be seen by reading other reviews here). My primary criticism is that I had hoped for a chapter or two about how to approach a poorly designed system and move it toward a clean design. There's really only a few spots where even needing to make a trade-off like this is recognized, and the most prominent ends with the proposed solution being to ship the feature on the deadline and ask for refactor time in the future. This almost never happens, since there's always another deadline on the horizon. Another place where the problem is briefly acknowledged makes the argument to always leave code with a better design than it was found in. This isn't always possible, however, as sometimes it's necessary to build iteratively around poor design (violating the consistency and complexity principles) before being able to eliminate it. In other words, on a large system, it's sometimes necessary to make a mess even messier before you can clean it up. I'd love to read the author's perspective on this facet of software design, and how to reason through such trade-offs. That said, given that my main critique is that I'd like to hear even more from the author on the topic of software design, I can easily recommend this book to every professional, or aspiring, software engineer. For more senior folks, it'll likely be a crystallization of wisdom you've already learned, in a form that'll be easier for you to socialize with the rest of your team. I, for one, would love to work on any team where the contents of this book are really internalized and applied.

Writing computer code provides a programmer incredible freedom, but writing good code that'll work in a team environment is a trickier assignment. Many coders fall back on whatever guidelines their manager issues, but that approach can obscure the real challenge. Not only is someone programming a computer to achieve a certain goal, but that person is simultaneously writing a letter to their future self and fellow programmers about what they are trying to do. Clear communication is as much a part of the challenge as getting the code to work in a maintainable fashion. In this book, John Ousterhout of Stanford University guides newer and mid-career programmers how to write better code. Computer programmers can be famously inflexible with personal coding standards. Whether one agrees with Ousterhout on ever issue or not - I certainly didn't - reading about others' understanding of coding increases your tolerance of other programmers. It simply makes you a better teammate. We all need better teammates, and it starts with you and me personally. He hits on all the major issues good programmers talk about with each other: when to write comments, how to construct self-documenting code, how to design deeply effective classes, and more. These are not challenges that are mastered once-and-for-all; rather, they are daily challenges with each programming assignment. Even as someone who has been programming for decades, he helped me see my craft in small, new ways. The obvious market for a book like this are newer and mid-career programmers. But advanced programmers often benefit from reviewing the main themes from a master craftsperson; indeed, at the very least, they can learn how to express themselves to their mentees. I slowly skimmed this book but slowed down for thoughts that I may not have had explored before. Coders of every ilk like learning by doing, but learning-by-doing has to be supplemented by coaching. Most supervisors don't have the time to do that in depth, so reading books about coding becomes essential. This one should certainly be on the reading list.

I think every person who has written a fair amount of code should read this book. Managers should buy it for their teams. It should be required reading for new team members (it doesn't long to get through - a few hours). It is NOT for beginner programmers in my mind - you will not have written enough code to understand the points being made. I'd say it's perfect for mid-level to advanced programmers. Why for advanced? Because they can quickly get throught it, and challenge some of their own design assumptions and practices. Mid-level programmers will find it a treasure. The title of the book is perfect, because it really is more philosophical and high-level. But that doesn't mean it's abstract nor boring. I find the ideas very applicable and easy to understand. The opening statements are very powerful - what is complexity, the difference kinds of complexity ("cognitive load" is an excellent concept), etc. It ends with a gem - you know your code is complex if you end up spending a lot of time fixing bugs in it. Complexity begets complexity. Don't let the critical reviews stop you from reading this book - so what, it ignores functional programming. Readers can buy books on that and contrast the desgin philosphy. Yes, it's OOP-based, but so what? It's easy to apply these ideas to non-OOP languages or concepts. Some complained about "3 chapters on comments alone". Not true - the three chapters cover different subjects, and provide excellent guidelines for commenting first (designing with your comments - kind of like writing a mini-spec, if you will), what constitutes a useful comment, and how to name variables. I found it very useful. The concept of "deep" versus "shallow" classes is very interesting, even if some of the reviews have criticized it. The author provdes a very nice clue to whether or not code should be broken out - do you have to keep flipping back and forth between the sub-task and the original function? Maybe it shouldn't have been broken out. Deep classes have simple interfaces and accomplish a lot for the caller. Shallow classes, on the other hand, require the caller to know about them, how to call them in order, etc. Good stuff. It's a short read. You'll scarcely find a book that's so short be so valuable. You can get through it in about 3-4 intense, focused sessions.

This book is comprised of short, easy-to-read chapters on what the author believes are proper software design practices, primarily for the C/C++ and Java languages. Most of the design practices are relevant for other languages and methodologies (functional, procedural, etc.) as well. Whether or not you agree with those practices is another question, and based primarily on which coding style camp you fall into. If you're a firm believer in Agile practices, test driven development, self-documenting code, or the latest coding standard fads you will likely take issue with this book. For example, the author prefers 'strategic' software design over 'tactical' design. The former means thinking about where the system is going and writing code that is maintainable and extensible over the long haul, as opposed to the 'tactical' approach of getting a minimal something running as soon as possible. Of course, such advice conflicts with modern practices such as Agile and associated software philosophies such as YAGNI (You Ain't Gonna Need It). If you agree with the author (as I do) and don't care much for some of these 'modern' ideas you'll love this book. On the other hand, if you live and breathe Extreme Programming, code in JavaScript, and believe that any program that takes more than two weeks to write will miss the market window, well, you won't find much to agree with here. To be fair, I have 40 years of experience in writing software for embedded systems, mostly in C/C++. There really wasn't much in this book that I didn't already know and practice. Like the author, I'm a firm believer in code with lots of well-written comments that document WHY (and not what) the code is doing. Like the author, I find test-driven development clumsy and ineffective. Like the author, I believe that simple interfaces and deep implementations are important, and that small function bodies create bloated, overly-complicated programs with a tendency toward "classitis" (the authors term for too many small classes). In other words, the author's biases match mine, and we both write code in software fields where the languages, tools and targets favor methodical, efficient, maintainable, and extensible code bases. I love this book. A developer writing a front-end for a cloud-based app using a framework-based language, where time-to-market is everything, probably won't. I recommend this book highly for software engineers who would like to take a break from the latest coding practice du jour and write well-crafted, easily maintainable code for a change.

I am CEO of an insurance company in Latin America. I have no major background in programming (even though I am mechanical engineer and took some courses on programing decades ago) but I found the insights of the book fantastic. It is very conceptual and easy to understand at least for a logical, structured, engineering mind. I am very grateful to have found it and look forward to exchange views with the autor who seems to be a very brilliant and humble person. Congratulations and thank you.

This book complements in many ways another essential book for anyone who wants to be an excellent software developer. I really like the focus on abstraction, the separation of interface and implementation, and the importance of simplicity to minimize complexity and improve performance.

This is a well written, succinct book with lots of good stuff to say on software design. I appreciated the way complexity management was used as the underlying theme for most or all of the suggestions. I generally agreed with most of the principles. The main thing I disagreed with was the author’s approach to method length.

A lot of what's discussed in the book is stuff I've already intuitively learned through trial and error over the years, but to have it clearly laid out in a detailed, well structured and methodical way is still very helpful for building a stronger mental model of things I've been thinking about for years. I wish this book existed when I first started my career. It's also a great resource to build alignment on system design goals in a team as well as defining a nomenclature around software design that helps clarify and facilitate discussion. While I'm sure not everyone will agree with everything discussed in the book, it still creates a great framework to be able to discuss software design and make conscientious decisions even when you decide to diverge from the advice in the book. I'm recommending this book to other developers in my company.

Great book! Very clear and pragmatic explanation of what matters in Software Design. Also recommend the The Pragmatic Engineer podcast episode with John Ousterhout (author) for a great overview of some ideas in the book.

Possibly my favourite tech book ever. Unlike other "clean code" books, it's not just a collection of advice, it unfolds a real theoretical framework that embodies the perks it touts in good design: simplicity, concision, consistency and pragmatism. It felt like the author somehow found just the right abstractions to describe what we pursue in good code. All served by spot on mental models (deep modules, information leakage), simple yet precise language and telling examples.

It's an amazing book where you get insights about how to build and maintain a software design. It's technical, but not a heavy reading, which makes it even more enjoyable.

The book's examples are mostly from programs running on an OS, with significant iron underneath. I mostly work with embedded systems, which are severely resource contained, often running on bare metal with a limited thread scheduler. Still, I found the book being generic enough to be applicable for that niche as well. I completely agree with Prof Ousterhout regarding shallow methods, variable duplication and the like being red flags. He repeatedly re-iterates the importance of hiding implementation details, which is actually one of the stated goals of OOP, The book tries to drive a point through: your system's long-term manageability depends on its abstractions, how you partition the task at hand into self-contained chunks with minimum, or preferably no interdependence between them. Yes, it cost a a lot of design time without cranking out any code, but this investment will be paid back during the actual implementation, and, more importantly, during the lifetime of the project (which with embedded systems is often decades). I especially like his talking about commenting the code and how comments provide meta-information that the code does not convey. The code should be obvious, sure. You read it and should know what it does. But will you know why it does it the way it does? Often the code is written on a particular way to accommodate peculiarities of the underlying hardware, and it incorporates a lot of knowledge/mathematics of a completely different field that the device services. You might have it all in your head when working on the project, but expecting the next guy (or even yourself a few years later) to know it all is not realistic. Comments can point out all those externalities and provide a rational for particular, possibly counter-intuitive, design choices employed in the code. Overall, I think the book is an eye-opener, at least it should make you think about abstractions, interactions, separation, generalisation, and, the most important message of the book, minimising complexity.

Very well written, it manages to frame many software design principles in a refreshing new, and above all, actionable way. The author presents many valuable lessons without getting bogged down by programming language minutiae that are irrelevant to the principles being presented. I highly recommend this to all software developers, regardless of their level of experience.