A Philosophy of Software Design

This book does not consider functional programming, or the fact that terrible software in modern times is often the result of layers of incorrect abstraction that are often induced by the overuse of "object oriented" (OO) programming techniques. Instead, it takes OO programming for granted as being a good thing (visible in its preferences for two OO languages, C++ and Java), and then it reasons in that domain, making it totally uninteresting to many potential readers. The book also assumes that formal design doesn't work (he calls it "waterfall"), and takes alternatives for granted. I doubt the author is even aware of his inherent bias, but it is incredibly strong.

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.

It may be suited for entry entry level engineers, and they find it an interesting read. I didn't learned anything, I am afraid, and was irritated at times when I disagreed with authors opinion that was being passed off as facts.What bothered me the most is the lack of rigor, for instance, he advocates for incremental design which costs 10-20% and if you don't it will make you 10%-20% slower after some point. The only motivation a graph with no units. It may matter if is 10% or 20%, as that is after all a factor of 2. Also, it's not really clear that once in a while 10% investment, let's call it 45 minutes is a very different cost than a recurring daily 45 minute overhead due to cost being a mess. I don't have any data to dispute the numbers, btw, but on the other hand, I have not seen any studies to support it either, and the author does not tell us where he is getting this from.His advise of avoiding lots of small functions as it means you will be bouncing all over the place to understand the code is not necessarily wrong. It adds lots of boiler plate, for example. Using an argument from the book itself, however, you could argue that good names and comments would mean you didn't need to read those lower level functions. The counter argument is that smaller functions are much easier to unit test. Then you have the unit test vs integration test discussion of course.There are 3 chapters on comments. Why?! I am towards the "good code is self-documenting" end of the spectrum, although I would say a lot of comments is often (but certainly not always) a code smell that suggest refactoring using better names, extracting code to function etc. I do like how he describes good comments as either lower or higher level than the code.The text editor example that runs through most of the book becomes trite. What I find way more interesting is when he talks about his experience with TCL (design mistakes, or the benefits derived from unit test suite), or towards the end RAMCloud and a specific implementation detail.

The author is not afraid to go against the common idioms of "good design" and he defines a new way to look at problem decomposition and abstractions. The way developers get thought to design systems in conjunction with software development trends too often leads to creating over-complicated software. Any software which is too complex to maintain will eventually be rewritten. The author explains a different approach on how to decompose problems and he defines a methodology to achieve optimal results over time. It also provides a list of red flags which, when found in a software project, enables the developer to timely recognize and correct design issues before they go out of hands.I'd recommend this book to the seasoned developer or software architect who has already seen a number of projects and designed a few systems. Which such experience the reader will quickly recognize many of the bad ways to design a system and the type of problems which bad design leads to.

As an experienced software engineer, I liked this book a lot. It's short, fairly general and high-level, much of the content seems like common sense, but it's still very helpful to have it clearly set down. The author emphasises the benefits of trying to stay in Technical Credit rather than Technical Debt (without using those terms). There is also a refreshing absence of fashionable methodologies.

Ousterhout ha avuto a che fare con grossi sistemi per alcune decadi, e sui sorgenti di Tcl io personalmente ho imparato cosa fosse la buona progettualità del software. Poi con il progetto Raft nato negli ultimi anni, l'autore ha affermato in maniera più chiara il ruolo da padrone che lui affida alla riduzione della complessità nel software. Ma non mi aspettavo che se ne uscisse con un libro del genere. Le più grandi lezioni su come scrivere buon software, che di solito si imparano in decadi, sono riassunte qui in maniera magistrale, con argomenti molto forti seppure non sempre scientificamente supportabili (per forza di cose). Il discorso non è solo di ordine filosofico: i consigli dati hanno immediata applicazione pratica. Questo libro vi farà diventare programmatori migliori, e se siete già bravi, vi ricorderà che la vostra sfida contro la complessità, anche se a volte vi sentite soli a farla, specialmente in alcuni ambienti, non è affatto vana.

This is an excellent book by an author who clearly understands software design.He gives an excellent set of principles for software design. He carefully explains how he's come to this conclusion after many years of software development, and he gives alternative approaches explaining the trade-off between different approaches.The actual software examples he gives come from operating systems. I have not worked on operating systems myself, so the examples were not entirely relevant to me. However the principles he is describing make a lot of sense and are very useful.

All in this book is right, most is said before, you cannot disagree.However, the book is not particular specific as to how to obtain software design with low complexity. It is high level guidance; it is left to the reader to make it into practical work. Too much theory, too few examples.