A Philosophy of Software Design

by John Ousterhout

Genres: Programming, Technology, Computer Science, Software, Technical, Nonfiction, Engineering

190 pages, Paperback

First published January 1, 2018

Reviews

[Cesar Diez Sanchez · Rating 3 out of 5]

I have mixed feelings in order to rate the book.

First of all, it's worth saying that I wish I had read this book when I was in college or just after starting my professional career. The author has clear and good ideas about how Software should be written properly.

I think this should be a mandatory read for everyone studying computer science, and it should be used as a tool while developing a small project. From a student point of view, I would probably give a 4 or 5 stars review.

I don't consider myself an incredible programmer, but I've been in the industry for a while. I'm going to give constructive feedback in order to try to help the author to create a second version of the book with some improvements.

Overall, the author's ideas about software development are good but either sometimes they are not transmitted in a clear way or/and the explanation is too educational. I don't know if the author tried to avoid using well-known terms in the software development world in order to tag those explanations, but I think it could have been a good idea using terms since the reader could assimilate those concepts easily. While reading the book I sometimes felt I got lost in the author's thoughts and non-contextual examples used in the book.

It could have been helpful for the reader to have a small open-source project as a guide for the concepts explained in the book. Well-documented commits in a repository could be used to define each of the refactoring steps towards creating a well-designed system.

Ideas brought from the Effective Java book and other concepts like hiding implementation details, using single responsibility principle, don't repeat yourself (DRY), continuous integration, continuous delivery, and so on; are explained in a very educational way and I think the author should mention some of these terms when talking about these concepts because it would help new developers to communicate what they've read with their colleagues.

The book's edition could improve since I've spotted some mistakes in the author's grammar and syntax. Hope that improves in a posterior edition.

Sometimes the author focuses on really small details that are difficult to digest when developing a product, like "general-purpose" and "special-purpose" interfaces.

Overall I agree with the majority of the concepts explained, but I think the chapter 15 "Write The Comments First" and the others chapters talking about comments could be misleading. Comments are good as an abstract way to explain certain kind of implementation, for instance when doing tricky things like developing APIs or specific case scenarios with algorithms involved. Instead, try to use good naming and right design patterns and concepts, the methods should be self-explanatory. I would change the title to "Write the Tests First" since MOST of the implementations can be understood by tests covering them. So instead of writing documentation explaining what your code does, try to write more tests to cover what the developer is trying to do. Tests are DOCUMENTATION and avoid bugs, so, since we code for humans and not machines, try to think about good naming and decompose code responsibilities and back them up with tests to let others understand what's your goal. I'm not saying we shouldn't write documentation, but if the system is well-written the "why" or purpose of methods/classes/interfaces could be justified by how they are grammatically expressed or by the usage of integration tests (they define what product wants).

I do agree with the author though, that TDD could sometimes not be a good way to approach programming.

Some key points of the book:
- Decompose your problems
- Delaying tests, documentation, and refactoring means not doing it. Later equals never. It's a rule I can verify it works in the industry.
- Composition over inheritance (I don't think the author makes emphasis enough on this). It's a very important rule that is going to help make behavioral changes in your classes. Inheritance should be used with caution since not doing it could lead to clashes with the "Liskov substitution" and "Open/Close" principles from the SOLID software design concepts widely used in object-oriented software.
- Single Responsibility principle and Inversion Control are probably the most important rules in Software Development.
- Code automation (Continuous Integration & Continuous Deployment)

To sum up: I've re-learned some concepts in a very educational way, which is good in order to take notes when teaching, but as an experienced developer, I already knew at least 80% of the ideas mentioned.

Hope this was useful.

[Sandro Mancuso · Rating 3 out of 5]

I really enjoyed the first half of the book, when the author discusses complexity, deep vs shallow modules, information hiding, general vs special-purpose interfaces, levels of abstraction, the criteria to split or keep code (methods) together, pull (push?) complexity downwards, and designing errors out of existence. It made me see modularity and complexity in a slightly different way.

The second half of the book is not so great. The emphasis on code comments goes against the idea of Clean Code. The chapter on name and the chapter on consistency are very simplistic, as most of the other chapters in the second half. Not much original content here.

The author’s take on “modern” software practices (or “software trends” as he describes), mainly about Agile and TDD, clearly shows an academic background instead of industry experience.

I recommend the book for its first half.

[Rafael · Rating 5 out of 5]

I really enjoyed reading this book. Ousterhout's book is a very brief book (170 pages), but it builds a thoughtful and solid work about how to design software to avoid complexity.

The book reasonings are a higher level of abstraction than the typical book about software design, however, it also turns to very good specific examples when it's needed.

I liked how the author is able to discover a convincing corpus of interesting principles, practices, reflections and "red flags" about the design of software by pulling out his fundamental thesis against complexity in software

The book is full of great insights. A lot of these ideas are not new in our field, but they are shown in a very clear way and, above all, the author relates each of them with the complexity leitmotiv. I especially like principles like "deep vs shallow modules", "different layers should have different abstractions", "design it twice" or "the increments in software development should be abstractions, not features".

Finally, I like the book is very courageous. Ousterhout dares to express his critiques and doubts about some ideas very well-established in the developers' collective conscience, like the "comments are always an error" of the Clean Code movement, agile development leading to a mainly tactical programming or TDD:

"Although I am a strong advocate of unit testing, I am not a fan of test-driven development. The problem with test-driven development is that it focuses attention on getting specific features working, rather than finding the best design. This is tactical programming pure and simple, with all of its disadvantages." (page 155)

I do not totally agree with some of these ideas, but unavoidably they are a good wake-up call to our community of dozed and brainwashed prisoners of the mainstream.

[Emre Sevinç · Rating 4 out of 5]

This turned out to be a mixed bag for me. Some chapters are really good, whereas some (e.g. "Software Trends", "Design for Performance", "Code Should be Obvious") are pretty shallow, not contributing much. Having said that, most of the chapters are examples of very clear writing, backed not only by strong pedagogical foundations, but also the industrial experience of the author that had to support complex software products used by hundreds of thousands of users; and I wouldn't expect anything less than that from Ousterhout.

Before going further, you have to realize that Ousterhout has a well-defined and limited scope based on his industrial and academic experience: if you're mostly working with C, C++, and/or Java, on some critical libraries, complex software products, or advanced research software that is linked to industry (e.g. RAMCloud), then most of the advice will make sense to you, outlining straightforwards methods and techniques of dealing with complexity in your, or, let's be realistic, mostly somebody else's, software designs. Of course, some of that advice is so generic that it'll even apply if you're working on LOB (Line of Business) apps, or boring, good old CRUD apps (just don't get overexcited).

I found this book to fall into the category of the following books:

- Code Complete
- The Pragmatic Programmer: your journey to mastery, 20th Anniversary Edition
- The Mythical Man-Month: Essays on Software Engineering
- Release It!: Design and Deploy Production-Ready Software
- Effective Java

For the chapters that are very short to be really useful, e.g. performance, I suggest that you read authors such as Brendan Gregg.

As a unique selling point of this book, I might add that it includes probably the most in-depth discussions on how to write and structure source code comments, and their relationships to source code control, overall documentation, pitfalls, etc. Almost all of the great software designers I know try to draw important and useful relationships between effective communication in natural language and software programming, and Ousterhout is no exception.

Another nice aspect of the book is something external to it: Ousterhout created a discussion forum (on Google Groups) dedicated to the book, and I strongly recommend reading some of the discussions and criticism because some of them will definitely enrich your understanding of the book, especially the discussions about practical, strongly-typed functional programming, which, in a sense, strongly relates to the author's "define errors out of existence" principle.

I can't say I learned much from this book, but I've still enjoyed it, and can recommend it to people who have a few years of software industry experience, or undergraduates working on software-intensive projects. Apart from that, I think I'll rely on this book when I need to communicate some of my ideas to junior software developers (some of the examples and communication techniques in the book are too good to ignore! ;)

[Rodney Norris · Rating 2 out of 5]

I gave this a pretty low rating for me. I still think the book is valuable to read, even though it frustrated me immensely personally.

I whole heartedly agree with the premise that software design is important and as developers we should be focused on reducing complexity. There are plenty of parts in this book I would give 5 stars, but there are others I would easily give 1.

I found this book incredibly polarizing personally. There are times the author comes off as condescending and arrogant. He likes to make broad statements about “most developers” which I found very frustrating. He reminds me of some of the most difficult developers I’ve worked with in my career. The ones who will bike shed an issue for days when you have a deadline, and easily forget that they are paid to solve problems and help make a business money, not write the best possible code. It doesn’t matter how good your code is if it doesn’t add value for someone.

I found his framing of “tactical” vs “strategic” programming comical. There are times for both throughout the life cycle of projects and companies, and it’s important to know when to apply which and to have honest conversations around it. Not to trumpet one as a zealot and demonize the other.

Given the authors experience, his point of view makes a lot of sense. When working on low level code the things he focuses on are more important. I’ve traditionally worked in product development which is why I have a differing point of view.

[Michael Dubakov · Rating 3 out of 5]

Book with a promising name, but very mixed content. Two good thoughts:

1. Modules should be deep. It is better to have fewer deep modules than more shallow modules
2. The increments of development should be abstractions, not features. When you need an abstraction, invest time and design it clearly

There are many good advices, but on my opinion the book is not deep enough to have this promising title. Also, it's a crime to spend 30 pages of 170 to how to write comments.

[Mircea · Rating 5 out of 5]

short. sweet. to the point.

in a world of agile puppets it is refreshing to see someone that takes a no bullshit approach and actually delivers.

i really liked it and i would recommend it to any software developer (orthogonal to how good you think you are or how long you’ve been doing this)

[Bartłomiej Falkowski · Rating 3 out of 5]

Interesting book. First part of the book and chapters about modelling and designing are precious.

What I liked:
- Great description of what an interface is and how important is to model it properly (deep module vs shallow module)
- Explanation of complexity in software
- Strategic programming versus tactical programming. Btw there's funny quote from this chapter: "Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado."
- One thing that was amusing and reflective at the same time - students' projects were treated as a data for "badly designed code" examples. It's not about making laugh at students :) It shows however that being at least sufficient at modelling requires years of practicing and learning.

What I didn't like:
- 20-30% of the book was about comments in code (!)
- book looks like it's compouned from two pieces - the first one is about software design (that is what it supposed to be if you look at the title) and the second one is about comments and other practical tips. Five stars for first part, one/two stars for second part.

To sum it up, it's definitely worth reading. It's not an enterprise / business or domain oriented view at the software modelling. It's more like academic view at particular design problem where many pragmatic tips and conlusions are provided.

[Andreea Ratiu · Rating 4 out of 5]

We read this book at work for a book club. As someone summarized it - 'it is a short book with several good advice'.
The book offers advice on how to reduce and control complexity in software projects.
I agree with some of the advice, I feel so-so about others. Overall, I recommend it.

[Jan Sabbe · Rating 1 out of 5]

I read this book as it was recommended as a better Clean Code. The latter has some horrible code samples and some extreme guidelines that can easily reduce readability of code. But in general, the principles lead to better code. A Philosophy of Software Design has better examples and more nuanced explanations. However I disagree with the preface, the premise and a bunch of principles, so I wouldn't call it a win 😉

Excerpt from the Preface:

David Parnas' classic paper "On the Criteria to be used in Decomposing Systems into Modules" appeared in 1971, but the state of the art in software design has not progressed much beyond that paper in the ensuing 45 years.

This is just nonsense. Eric Evans made massive contributions to the field by writing Domain Driven Design. Martin Fowler (with help from Kent Beck and others) similarly pushed the state of the art forward by cataloging code smells and concrete improvements in Refactoring: Improving the Design of Existing Code. These are just two examples from the top of my head.

Premise
Essentially, the book suggests certain design principles to reduce complexity, as it believes reducing complexity is the most important goal of software design. I disagree. I think correctness is also an important goal. Often those goals are aligned and related. However occasionally it would be better to increase complexity if it reduces the potential of bugs.

For example, the author mentions adding a comment to specify the units of 'textHorizontalPadding', or use naming conventions to avoid bugs around mixing up physical block numbers versus logical block numbers in a file. One of the principles in the book is adding comments to make the informal aspect of an interface more clear.

I would argue that introducing a wrapper types like Pixels, PhysicalBlock, LogicalBlock make way more sense. Essentially I would try to formalize the informal aspects of my interface first.

Yes, they are 'shallow' classes (to use the term of the author). These are less general abstractions than ints or raw pointers (according to the author general abstractions are better than specific ones). It arguably increases cognitive load a little bit, however the compiler will now help prevent bugs and improve correctness. Previously implicit concepts are now explicit which helps communication in a team as well.

Excerpt:

Long methods aren't always bad. For example, suppose a method contains five 20-line blocks of code that are executed in order. (...) there's not much benefit in moving each of the blocks in a separate method.

I disagree. Yes, it's sometimes tricky to find good names. But extracting those blocks in private methods does help with readability. The data flow is instantly more easy to follow. What variables are used in a code block, and does it output anything? It keeps the same abstraction level in a method instead of jumping from a *char array to a high level business concept. Because you're extracting to a private method, you're not increasing the cognitive load of the callers either. It would be even better if you are able to identify missing concepts and extract package-protected value objects representing a previously implicit concept.

Excerpt:

Goto statements are generally considered a bad idea, and they can result in indecipherable code if used indiscriminately, but they are useful in situations like this where they are used to escape from nested code.

Spoiler alert, it wasn't that useful. I'm sure there are situations where using goto is a good idea. But I haven't come across a good example and that includes the example in the book. Don't tell me try/catches are mostly bad (I mostly agree!), to then recreate it with a goto statement.

Summary

If you're looking to get better at software design, I would skip this book. The book was written in 2021, but it pretty much ignored everything after that paper in 1971. You'll miss reading about making the implicit explicit, pure functions, immutable value objects, statelessness, and making impossible states impossible. It does have some interesting bits, but other books have covered those in a better way.

If you haven't read them, go for the Refactoring book and the DDD book from Eric Evans first. I also enjoyed Domain modeling made Functional by Scott Wlaschin.

[Natalie · Rating 5 out of 5]

The book I wish I had read when first began my career in software engineering. Ousterhout makes a compelling, logical case for addressing complexity in software with simple designs augmented with clearly communicated documentation, rather than prioritizing getting something working as fast as possible. A philosophy that may seem like common sense, but an important one that should be regularly reviewed by any dev, no matter what stage in their career.

Linus Torvalds, on the beauty of programming: "It’s still hard to explain what can be so fascinating about beating your head against the wall for three days, not knowing how to solve something the better way, the beautiful way. But once you find that way, it’s the greatest feeling in the world."

[Aleksandar · Rating 3 out of 5]

Very good conversation starter, but very little more. Contains couple of interesting ideas, such as eliminating errors out of existence, however seriously lacks depth. In addition, most of the examples are too simple and rarely stress the importance of a principle. It's still worth reading if you want to start thinking about software design.

[Ignacio · Rating 4 out of 5]

It's interesting, but it's mostly a summary of topics that you might've already learned somewhere else in other really must-read books.

[Sebastian Gebski · Rating 3 out of 5]

The farther, the worse. It starts really well, by applying the theory of complexity to software design, but the final chapters felt like the author has no idea what to write about ... So e.g. I loved the idea of deep/shallow modules (I think it's a very visual concept that really helps) or the approach to consistency (and it's really worth emphasizing, because so many Engineers do it wrong), but OTOH after chapter 10-11 there was almost nothing worth mentioning (chapters about comments were literally a waste of time, same for chapter about trends, and the final one - about performance - I don't even know how to summarize it :D).

Very uneven book. Hence the rating which is somewhere in between (3 stars) great & mediocre.

[Andrew Barchuk · Rating 4 out of 5]

I really like the premise of the book and the topic of software complexity it tries to tackle. There are many ideas that can be refined and fleshed out better. The second edition of the book can be much improved. There're certain approaches that I do not agree with or are not universally true in my opinion. Still the book got me thinking about some important issues which I'm thankful for.

[Rose Smith · Rating 5 out of 5]

I think this book is my third time. We read it as part of a book club with mostly book club graduates. Again, a GREAT book. The best part of the book club was the chapter-following discussions!

[Bruno · Rating 3 out of 5]

This is a kind of tricky book to rate... The advice included is good and worth knowing, but the book discussion itself seems a bit too shallow (and way more academic oriented).

This is a book that you will read quickly, in a couple of hours, and might come out with one or two things stuck to your mind. For example, I particularly liked the discussion regarding tactical approach vs strategical approach to development and I think this is a thing more people should be exposed too, the sooner the better.

[Dmitriy Rozhkov]

I'm not giving it a rating. This is a rather controversial book, though all the examples are spinning around C and Java. Of course programming on the least expressive language one would recommend using GOTO statements. Despite being amused by the statement that OOP is _the_ way to design software, I would still recommend the book as a good source for thoughts and self reflection.

[Leandro López · Rating 4 out of 5]

It would have been nice to have more code examples of all the discussed topics. Having said that I think it is a great cook to have on your shelves. Not mandatory, perhaps, buy a great compliment to other books on software design.

[Jon Kartago Lamida · Rating 4 out of 5]

This book is a good book to complement Code Complete, Clean Code and Working Effectively with Legacy Code. To summarise in one sentence this book is all about managing complexities when writing software. The book is a summary from John Ousterhout course CS 190 Software Design Studio in Standford. That makes all the suggestions in the books although still an opinion but based on learning and feedback settings in the class.

Some concepts are not new and I have read it somewhere else. Some new concepts which I haven't read anywhere that I would like to highlight are tactical and strategic programming and also about deep and shallow modules.

Tactical programming is when focus to get things done. It is famous by the statement "move fast and break things". A strategic programming summary is when we realize "working code is not enough". I have read it often that the longest phase in the software lifecycle is not software writing. It is maintaining software. So the software needs to be written not only just to make it works but also to make it easy to read and to change. This can be done by strategic programming.

Deep modules are modules with a simple interface but powerful functionality. Shallow module in the other hand shallow modules are modules with a large interface but simple functionality. Most of the time, modules should be deep.

There are many other discussions around other topics too. Like other software design books, some of them seem opinionated. But the writer itself mentioned that not everyone will agree in the book suggestion and it is fine.

[Przemek · Rating 4 out of 5]

Quick read. I wish we had more of those, not technically hard but still meaningful, covering an interesting topic. The author is a renowned computer scientist and author of TCL/TK. I think that the title is quite bad. There is little philosophy, it's more like a collection of good practices and some interesting thoughts on sources of complexity. Design is there but on a lower level then I expected, class/module level dominates. It might be impactful for many folks, especially self-taught folks but more senior people should not be bored. The focus is on the object-oriented world but not mentioning functional programing when dealing with complexity etc seems to be an omission for the book from 2019.

[Daniel Dao · Rating 4 out of 5]

It was a pretty good book. I really liked the first half and the second half kind of fell flat. I wish there was also more code examples. In my opinion this is a solid book for a person a few years into their careers. The lack of code examples makes it hard to actually imagine use cases sometimes, but with more code exposure, then it's easier to imagine.

[Povilas Balzaravičius · Rating 3 out of 5]

The anti-Uncle-Bob-book ;) Good ideas and I agree with bunch of those but the book itself become a bit boring after the first half.

- Interfaces must be small & narrow.
- Modules should be deep.
- Comments are important.
- Design abstraction before coding.
- Put effort into naming.
- Optimize when needed, measure.
- Optimize the critical path.
- Overriding methods leads to complex code.

[Enrique · Rating 5 out of 5]

Absolutely loved it. All the aspects covered in this book aimed towards the same goal: reducing complexity. But I love that it discusses compromising and using your judgment when facing choices (e.g. performance vs readability, etc) and provides some guidelines, unlike *other* books which have an authoritative, even dogmatic, tone.
Every programmer should read this book.

[Derek · Rating 5 out of 5]

I enjoyed this book a lot and I also found James Koppel's book review and the related HN discussion an interesting read. Comparing these two different views I think I agree with the whole "deep modules" idea more. What James described that is "more complicated than the implementation" seems to be a formal software specification to me, which should be way more complex than an interface. And even though there are "plenty of programming languages that do let you write them (the specs) down and check them", I've never seen anything like this being used in large-scale production systems.

This is not a "hardcore" technical book so it's true that most of the ideas should have already been familiar to a senior software engineer. I find two parts especially interesting and helpful.

The first part is the whole "deep modules" discussion and the problems related to shallow modules, e.g. the information leakage caused by shallow modules, how to make interface general purpose but implementation special purpose at the beginning, i.e. make the code just a little generic, how to have better abstraction layers so we can use fewer pass-through methods and pass-through variables as these are shallow methods anyway, how to pull complexity downwards so the users of the interface can have an easier time (this is also a good example of "learning an interface should save you work, not cost you work" from the HN discussion).

The second part is some very practical comments when it comes to writing comments and variable naming, like how to make sure your comments are not actually repeating the code, how to make cross-module design decision comments, when it is OK to pick short names over long names, use comments as a design tool, etc. I might have seen most of these advices here and there but I feel it's valuable to read these practical advices as a whole.

BTW - it's obvious to me that Prof. Ousterhout hates Java I/O interface so much that he has used the notorious `BufferedInputStream` interface as a negative example multiple (at least 4) times in this book.

[Vicki · Rating 3 out of 5]

This book has some positives, as well as some negatives, and I can't say that I would or wouldn't recommend this book one way or the other - I think it's definitely at least worth a skim, especially since it's pretty compact.

The positives:

+ Good enumeration of what clean, concise code looks like - not a lot of books have this discussion, so it's good to put it out there.
+ Good discussion of code tradeoffs
+A good launching pad to explore other concepts in computer science: pointers, memory leaks, heap, garbage collection, HTTP endpoints, etc.
+ Really good discussion of good comments, why they're important, and how to write them

The negatives:

+ Extremely biased towards Java/C/C++/languages that have implementations for abstractions like interfaces. Coming at it from a Python perspective, it's not as effective because Python doesn't have the same types of OOP culture (although with the release of 3+, type annotations, etc, the community is working towards it).

+ Very based in academic theory. The author is an academic, so it makes sense, but some of the comments would hold no water in a business setting: i.e. explaining to a business owner that you need more time to write code intentionally versus working towards a deadline - that's just not how things work and perhaps a separate book should be written on this. Also, the idea that classes/modules should be deep is a definite code smell for me personally. I'd prefer to read 10 100-line classes than one thousand-line class, for sure.

+ The examples the author uses from his courses are disjointed and don't make a lot of sense outside that context. It would be nice to have one single example to walk through the entire book.

+There's a discussion about why good variable names are important, but not much depth about HOW to create good variable names - should have been a longer section.

[Mansur Mustaquim · Rating 2 out of 5]

This is not a book on the philosophy of software design. This book is advice on how to write good code. Similar to Code Complete and Clean Code but not as well written.

The language used to convey ideas is often imprecise. For example, abstraction is defined as "a simplified view of an entity, which omits unimportant details". The catch in this definition of abstraction is recognizing what constitutes "unimportant details". This problem is addressed in a frustratingly circuitous manner:

In the definition of abstraction, the word "unimportant" is crucial. The more unimportant details that are omitted from an abstraction, the better. However, a detail can only be omitted from an abstraction if it is unimportant. An abstraction can go wrong in two ways. First, it can include details that are not really important.... The second error is when an abstraction omits details that are really important."

In other places the advice is unconvincing. For example, saying that the use of goto is justified in Figure 9.2 doesn't appear to be merited as it is precisely the same code layout and control-flow that would be achieved from using a try-catch block.

It seems to me that the reader probably already needs to be a good enough programmer to recognize what the author is trying to convey.

[Ahmed Khattab · Rating 4 out of 5]

This books contains some interesting ideas, some make sense.

The parts i liked about the book is how the author points out Complexity and Obscurity. He examines the reason that leads to incremental addition to complexity. The reasons are your normal reasons, poorly-named variable, modules that expose too much information, etc.

I also liked how he emphasis on code-comments. Indeed, code comments are an investment that you make into the project. He debunks the excuses programmers bring so as to not comment their code. However, he also tells that we must try to express everything in code. But, by nature, some complexity cannot be expressed in code, like why there is a magic number floating inside a method, when this happens, a comment would do your coworkers, and your future self a huge favor.

His discussion on shallow-vs-deep modules is debatable. He argues that a module/class/interface need to be deep and expose a minimal interface to the user. He argues that a deep/long module will encapsulate all of the complexity inside itself, exposing simple interfaces to the user. He does not mention the limit on deep modules. If carried away to the extreme, this would result in files that are over 1000 lines. Personally, i would rather jump between 50 to 100 line files, that being forced into reading one big 1000 line file. The examples he give also do not clear the confusion.

[Viktor · Rating 3 out of 5]

The author of "A Philosophy of Software Design", John Ousterhout, is working in Stanford and has taken part in some complex software projects such as the TCL programming language. Therefore I'm pretty sure that he is a very competent engineer and designer. I must admit that this book has some good advice and I believe it can be very useful to students and less-experienced developers. I particularly liked the chapters about complexity, tactical/strategic programming, information hiding, abstractions and designing stuff twice.
Nevertheless, I think the book has lots of areas that need improvement. First, there is not a single recommendation on further reads, which leaves the curious reader empty-handed. Second, most of the chapters are too short. This has some advantages, but overall I would prefer a deeper discussion, which might also include some counterarguments, or more examples. Third, I think the exercise approach can be really useful, because it makes readers stop and try to apply a given advice themselves. Unfortunately there is only a single such problem provided - in Chapter 13.

[Ari · Rating 4 out of 5]

A short, highly readable book about software design -- primarily at the level of "classes, what they should be like", but with some insights at higher and lower levels of abstraction. Reading this, I found myself generally nodding along and thinking that it was a clear exposition of something I essentially believed.

Ousterhout is a very senior, very successful computer systems researcher and designer. He has the credibility to write a book like this.


A few big ideas that stuck out --
- Ousterhout thinks it's easy to err on the side of too-small classes and functions. He argues that classes should be deep, and if you notice a class is a thin wrapper, that is a warning. More generally, a class should be implemented with different abstractions than it exposes in its interface -- a class that doesn't create a new abstraction is likely too thin.
- Keep things together that should be read together. This can be hard to do when a new feature has to be implemented cross-layer, but one should try.
- Think through several possible designs before you start coding.


Disclaimer: I have met and deeply respect the author. Also, I overlapped in graduate school with his daughter.