A Philosophy of Software Design

An opinionated collection on how to design software focusing on its complexity.
While a lot of design principles feel close, there's little to none valuable information about them. Typically there's a vague discussion-like description of the problem with indecent backing (author's feeling, observation from a couple of student solutions), followed by “examples” that really don't provide additional value to the point.
As a recent book on design principles it missed the chance to have a proper literature analysis on the topic.

IMO only the first 2-3 chapters were engaging. Outside of that pretty underwhelming.

Great book and definitely one I'd recommend, but not all chapters equally.

It starts off strong. It defines complexity for the purposes of the book and why it's problematic, and then goes on for a few chapters on how to avoid it. Separates strategic “focus on the design” coding and tactical “get it working” coding, and spends the whole book emphasizing that you want to be strategic most of the time.

The next ~8 or so chapters go about what is good design that reduces complexity. I recommend chapters 4 (modules should be deep), 6 (general-purpose modules are deeper), 7 (different layer, different abstraction), 8 (pull complexity downwards), and 10 (define errors out of existence). They have solid and concrete advice that I haven't seen elsewhere, at least not explained so clearly.

Chapters 12 and onward have some interesting stuff but I think it declines compared to the first half. Skim through them and see if anything catches your eye. Two interesting ideas I noted down are:
* From Chapter 19 (Software Trends), that in agile development we should consider the iterative unit of development the abstraction and not the feature. That is a way to combine the quick iterative approach of agile with the strategic programming approach encouraged by the book.
* From Chapter 20 (Designing for Performance), a way to approach improving performance while keeping the code clean - by focusing on what the “ideal state” would be of the critical path in terms of performance and then approach it following the rest of the advice of the book.

Overall a book I liked a lot and would probably recommend the first half of it to pretty much anyone.

Excellent book. I loved the way it is written, concise and easy to read.

I would recommend this book to anyone that takes software development seriously. I have read a few comments mentioning that it talks too much about comments, but I disagree with those and agree with the author, comments are very important and it is really hard to write clear, effective and useful comments.

I would say that a chapter on code reviews is missing, following the same line of thought that for comments, I think code reviews are not easy to do or obvious. Bad code reviews can make a project fail and I know some people will disagree but in my opinion, software design is way more than code.

Fundamental concepts for people who want to improve their code. I kind of agree this book is more for new graduates than for experienced developers, but it can serve as a reference when trying to explain or justify one of the concepts explained in the book. (for the ones you agree with at least)

I have a weakness for generally applicable programming books because they'll be valuable longer and are a better use of my time than learning a language, framework, or something similar. For example, [b:The Pragmatic Programmer: From Journeyman to Master 4099 The Pragmatic Programmer From Journeyman to Master Andy Hunt https://images.gr-assets.com/books/1401432508s/4099.jpg 7809] is one of my favorites.This book feels like a spiritual successor to The Pragmatic Programmer and I'll recommend it to any experienced developer. There are some oddities (the author recommends goto at one point), but for the most part the recommendations are good and serve as great discussion topics with co-workers and other developers.