A Philosophy of Software Design, 2nd Edition

This book is about software complexity and how to reduce it by design. John Ousterhout teaches you how to do it with no dogma by telling you how, why, where and when you are taking it too far. It will help you manage the complexities of software.His philosophy challenges many popular notions you find in the current state of the software development industry, especially those you see in the agile world preached by the gurus of the agile manifesto. I recommend you to read this book to provide nuance to that discussion.

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.

I enjoyed this book even without agreeing with all of it.The focus on up front thinking was appealing - I’ve fallen prey to a “just TDD and it will work.” Most the time TDD works well for me is when I already have a strategic direction in mind.The author encourages a comment driven development style - which I am not buying. I do really like the idea of writing a README before writing code for a new project or library, to really start from the users perspective. So it’s more a limited objection I have.I really don’t find comments in internal representations helpful unless there is some really unapparent reason for an implementation. Otherwise it’s a smell that the code isn’t readable. However I have come around to documenting the public facing part of an API more extensively. It encourages thoughtfulness.His starting chapters on complexity and obscurity, and how these two factors can impede development, were spot on. I also am a fan of anyone that pushes for consistency at a company, too many devs have pedantic arguments and pick some one off approach for their repo, just becoming a pain in the ass for all their teammates who have to support their one off approach.

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.htmlA 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.

Helpful thoughts on how to either eliminate or complexity in software systems. Would have enjoyed his thoughts on the complexities involved in designing libraries and frameworks, but he does not address these issues directly

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.