A Philosophy of Software Design, 2nd Edition

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.

Since 2016, my job has been to teach software design at the advanced level to professional engineers. I run workshops, speak at tech companies, and blog on software design. So when I heard of this book, I naturally took a look to see if I could recommend it to students. PoSD is best read as a tactical guide of how-to’s. About a quarter of it is spent on naming and comments, and much of the rest is about specific patterns. His few attempts to jump from tactical advice to principles are either done by trying to blur together similar-sounding tips, or are hamstrung by his inability to see the meaning of a program beyond the code. He demonstrates the lack of principles comically in Chapter 19, where he promises to apply the books’ “principles” to several software trends, and then fills the rest of the chapter with standard (but solid) advice on unit-testing and OOP, with nary a reference to the rest of the book. On the whole, the book’s advice is higher-level than beginner books like Clean Code, but most of its contents will be familiar to a senior software engineer, and the novel parts are hit-and-miss. A huge underlying theme of the book, and one of its few novel parts, is Ousterhout's idea of deep modules: modules should have an implementation which is simpler than the interface. This sounds elegant, and impossible to argue with. Unfortunately, it's also objectively wrong. Further inspection shows that actually many common abstractions like stacks fail this test, and even Ousterhout's own example of a deep module has an interface which is far more complex than he claims. Overall, Ousterhout misses the deeper notions of complexity, the kind which is about what a piece of code means and how it may be used and how it may be changed, rather than the kind that can be gleaned by glancing at the code. This is a major blindspot which damages the book significantly, and limits his ability to give precise advice. When Ousterhout tells you do reduce complexity, it often sounds like telling someone going on a date or interview "just be yourself:" the advice only works if you already understand complexity. Despite that, there is a lot of really good advice in this book, and it's explained with clear and concrete examples. I especially enjoyed his sections on comments. While I don't agree with everything in that section either, there are some really good points that I hope become common practice, and which I have not seen others write about. His chapter on performance engineering is also gold. So, read the book, savor the advice, but take his justifications with a grain of salt and know that they're not universals, because there are deeper principles to be found. I wrote a much longer review on my blog, going into these points in more detail. For my full review, see: http://www.pathsensitive.com/2018/10/book-review-philosophy-of-software.html A Philosophy of Software Design is a good book, but not a great one. But it's one of the only books of its kind out there. Hence, I am proud to recommend it to all junior-level software engineers.

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.

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.

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.

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.

This book talks about a lot of general concepts that can help make your software more readable, easy to use and maintainable. How ever a word of caution. I think you need at least a few years of industry experience to make sense of this book. You need to have seen the bad hard to maintain spaghetti code to realize that the concepts talked about in this book actually makes a lot of sense. Unlike some of the comments, I thought the book did a decent job with giving examples. An example this book talks about the classes for reading files in Java and why they are more harder to use than they need to be. In Java you need at least 3 lines of code to read a file. In Python this can be done in one line. The concept he introduces to avoid this problem is called temporal decomposition. I want to make this book a mandatory read for all developers in my team.

Very interesting book, with modern view on software development. What I really like about this book that it's up to the point without extra information. I also like John's honest opinion on different topics, which are in some cases are different from what we here on media and what we study in colleges. For instance I also learned about: 1. Tactical versus strategic approach. 2. Tactical tornado programmer - prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. 3. The extreme of the "classes should be small" approach is a syndrome called sclassitis, which stems from the mistaken view that "classes are good, so more classes are better" 4. Pass-through variables 5. Splitting and joining methods. "Long methods tend to be more difficult to understand than shorter ones, so many people argue that length alone is a good justification for breaking up a method. However, length by itself is rarely a good reason for splitting up a method. In general, developers tend to break up methods too much. splitting up a method introduces additional interfaces, which add to complexity. It also separates the pieces of the original method, which makes the code harder to read if the pieces are actually related. You shouldn't break up a method unless it makes the overall system simpler. 6. If it's hard to find a simple name for a variable or method that creates a clear image of the underlying object, that's a hint that the underlying object may not have a clean design. 7. Comments belong in the code, not the commit log. 8. If information is already documented someplace outside your program, don't repeat the documentation inside the program; just reference the external documentation. 9. Don't change existing conventions. Resist the urge to "improve" on existing conventions. Having a "better idea" is not a sufficient excuse to introduce inconsistencies. 10. One of the risks of agile development is that it can lead to tactical programming. Agile development tends to focus developers on features, not abstractions, and it encourages developers to put off design decisions in order to produce working software as soon as possible 11. The problem with test-driver development is that it focuses attention on getting specific features working, rather than finding the best design.