This Post Has 7 Comments

1. You’ll probably either love it or hate it
   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.

   Reply

2. Beautifully-written, but with blind spots
   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.

   Reply

3. Esse livro é uma rara exceção no mundo de hoje. A didática do autor é fascinante e sua habilidade de transmitir o que realmente importa é notável.Mudou minha mente como programador e resolveu muitos conflitos que me afligiam.É um texto conciso, claro e objetivo que todo programador deveria ler (e aplicar).A lucidez do autor em falar de temas tão comuns aos programadores vem tanto da sua experiência prática como dos seus anos lecionando a matéria, o que é sem dúvida um enorme diferencial na relevância desse texto.Simplesmente fantástico. Recomendo fortemente !

   Reply

4. Para mi, un libro indispensable para personas en la industria, pues provee consejos sobre cómo escribir código de calidad

   Reply

5. I’m a professional software developer with an honored computer science background. This book makes me feel like I’m learning the alphabet again. THIS is how software systems should be written. Not the actual mess you find in nearly any practical project after 3 months or the #1 bestselling “clean code”.The book transports decades of wisdom in writing good code and actually leveraging OOP in practice. Not the inheritance hierarchy mess or compositions of a thousand shallow classes that you’ll see everywhere in practice. COMPLEXITY IS THE ENEMY!All negative reviews do not contradict any of the author’s points (content-wise). They simply argue that his book contradicts “Clean Code” by uncle Bob, hence it must be bad. Obviously this is acting like a cult.”Clean code” is just a mixture of basic advice (good) and logic-contradicting mantras (bad). E.g. “write no comments, instead use method names”.Points I disagree with in the book:- TDD will not result in fast “feature push-out”, much rather it’ll emphasize the design-thinking approach, because one has to design the class/method “from the outside”.- Tactical vs. strategic programing is displayed a little black and white for my taste.- The performance chapter is a bit generic (other than that one must benchmark). For 99% of devs, performance must not be considered, so this chapter should rather be a addendum.- “Defining errors out of existence” can be practical (then go for it!), but can also result in a huge additional implementation.- Unit-tests can also hinder “big” refactorings. Because when you change major parts of the system design, those unit tests will not work anymore and must be refactored as well.

   Reply

6. Book explains concept really well. This will change your perspective regarding code and help you to improvise your self while writing code.

   Reply

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

   Reply