John Ousterhout: "It's more important for a module to have a simple interface than a simple implementation."<p>Richard P. Gabriel in <a href="http://dreamsongs.com/WIB.html" rel="nofollow">http://dreamsongs.com/WIB.html</a> : "Simplicity -- the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation."<p>Ousterhout here is advocating The Right Thing, as opposed to Worse is Better. Unfortunately Worse is Better has become the dominant approach and it will be difficult to change that.
I want to politely disagree with the comments here telling that this book should be categorized as a "undergrads book". This is a way to neutralize the content of the book for a broader audience, that is, we are doing everything wrong in most software development environments.<p>Moreover the author commits a big mistake in saying that Google is a good example of clean software design. Talk with people inside the company to get a real picture, it's full of monsters that you have to maintain just with "tactical programming". This book is very well applicable inside Google as well.
I saw some reviews that claim the books just presents common knowledge. Keep in mind it is aimed at undergrads.<p>I personally think the author is to harsh on "tactical programming" (solving problems locally without the big picture in mind). I agree with someones note on HN that tactical programming is fine till you get a product market fit. Technical debt has not to be paid back if the product fails.<p>I try to design strategically for overall architecture and don't care for most of the rest (in worst case you can refactor later).<p>If 9 out of 10 startups fail you can have huge savings. If you have enough success that it matters then you have the resources to improve.
This was a fantastic book. It is definitely not for undergrads, or just undergrads. I think it even more important for people actually working on production systems. Even better, it provides some language for people to share when doing code review about how to design their APIs better.
I've found this book to be a nice antidote to the damage done by excessive Uncle Bobbing. I.e. if you give your undergrads "Clean code", also give them this book to prevent them from becoming mechanical DRYers who think good code equals avoiding duplication.
Side note: I find it really weird that a book about software design released in this day and age has no plans for an ebook edition[1].<p>I've had this book on my radar since it came out, but no library near me is going to stock it, and I just don't have the space in my tiny apartment for books unless they are very important to me.<p>[1] <a href="https://twitter.com/JohnOusterhout/status/989581205799452672" rel="nofollow">https://twitter.com/JohnOusterhout/status/989581205799452672</a>
I've yet to finish this book yet, but it's definitely not just for undergrads. There is a lot of things in it that seem obvious when stated, but are either good reminders, or genuinely well stated language for a domain.<p>One example that stands out to me is deep vs shallow classes.
This [1]post on Reddit says something similar and really is true. Most of us engineers tend to neglect design. The fusion of good code and good design can set you up for success (after product market dit obviously)<p><a href="https://www.reddit.com/r/Entrepreneur/comments/9ay8fq/design_helps_software_companies_grow/" rel="nofollow">https://www.reddit.com/r/Entrepreneur/comments/9ay8fq/design...</a>
I use 'A Philosophy of Software Design' as my goto-list for reviewing pull requests. It has a great set of points that apply across a wide variety of applications.
The author gave a talk on this book at Google recently: <a href="https://www.youtube.com/watch?v=bmSAYlu0NcY" rel="nofollow">https://www.youtube.com/watch?v=bmSAYlu0NcY</a>