Goodreads helps you keep track of books you want to read.
Start by marking “A Philosophy of Software Design” as Want to Read:
A Philosophy of Software Design
Rate this book
Clear rating

A Philosophy of Software Design

Paperback, 190 pages
Published April 6th 2018 by Yaknyam Press (first published 2018)

Friend Reviews

To see what your friends thought of this book, please sign up.

Reader Q&A

To ask other readers questions about A Philosophy of Software Design, please sign up.
Popular Answered Questions
Dylan Meeus FWIW, I read the kindle ebook version and that was fine. Code snippets are always a bit challenging, but they are quite concise and don't necessarily …moreFWIW, I read the kindle ebook version and that was fine. Code snippets are always a bit challenging, but they are quite concise and don't necessarily add a ton of value.

Community Reviews

Showing 1-30
Average rating 4.16  · 
 ·  1,602 ratings  ·  233 reviews

Start your review of A Philosophy of Software Design
Cesar Diez Sanchez
Aug 13, 2018 rated it liked it
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
Sandro Mancuso
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.
Sep 23, 2018 rated it it was amazing
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 s
Jan 19, 2019 rated it it was amazing
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)
Emre Sevinç
Aug 17, 2020 rated it really liked it
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 le ...more
Rodney Norris
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
Michael Dubakov
Oct 27, 2018 rated it liked it
Shelves: programming
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.
Andreea Ratiu
Oct 02, 2018 rated it really liked it
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.
Jun 06, 2021 rated it it was amazing
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:
Sep 05, 2018 rated it liked it
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. ...more
Nov 10, 2018 rated it really liked it
Shelves: development
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. ...more
Sebastian Gebski
Mar 15, 2019 rated it liked it
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 lite ...more
Rose Smith
Dec 05, 2019 rated it it was amazing
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!
Andrew Barchuk
Aug 29, 2018 rated it really liked it
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. ...more
Jon Kartago Lamida
Jan 02, 2020 rated it really liked it
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 conce
May 31, 2020 rated it really liked it  ·  review of another edition
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 b ...more
Daniel Dao
May 25, 2021 rated it really liked it  ·  review of another edition
Shelves: reference
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. ...more
Mansur Mustaquim
Dec 31, 2018 rated it it was ok
This review has been hidden because it contains spoilers. To view it, click here.
Aug 01, 2018 rated it really liked it
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 t
Carlo Corti
May 30, 2019 rated it liked it
I really liked the first half of the book where the author talks about complexity, information hiding and obscurity, tactical vs strategic programming, modular design even if these topics were discussed at high level.
I would have liked these topics to have been discussed in more depth.

In the second half, as supporter of the Clean Code culture, I didn't like all the emphasis on comments simply because I don't think that comments are the best way to document software. In my career, as a personal
Ondrej Sykora
Mar 01, 2019 rated it really liked it
tl;dr: if you're a software engineer, I strongly recommend reading this book.

The book tries to answer a very complicated and ambiguous question: what is good software design. The main thesis (though perhaps not explicitly stated) is that the quality of the design is strongly correlated with the level of abstraction and the simplicity of interfaces. Whether this is the right definition is debatable, but the author does a good job arguing his case and supporting it with examples.

Two reason why I
Vitor Capela
Jun 30, 2019 rated it liked it
Like a few other reviewers, I think the first half of the book is good; the second is more of a mixed bag, with a lot more subjective points (such as what's the result of TDD, or the practice of commenting).

On the whole, it's a short introduction to many ideas — especially to that of the importance of thoughtful design, a topic somewhat muddled by the conflation of the practice agile development with code being the first and foremost tool for building systems. The amount of benefit you will per
Aug 31, 2019 rated it liked it
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 bet
He says it up front and it's true: this is an opinion piece. To be fair, maybe I should have put the book down at that point.

The book does not deliver the depth its title promises. There is no thinking or logical argumentation going on. Only arbitrary surface level intuitive heuristics. I considered many of the statements made as plain wrong or even damaging, to a degree where reading was constantly infuriating. This short read is also shallow and redundant. I just expected much more from a prof
Matt Diephouse
Mar 14, 2019 rated it really liked it
Some portions of this book really resonated with me. I even shared some of them at work. The general approach of constantly investing in the software and improving the design of the system is something I feel very strongly about.

But this book was also a little less than I’d hoped it’d be. I’m not sure it’s at the level where I could share it with a junior engineer: it didn’t have the depth of explanation or the careful walkthrough of application that I’d like to see.
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. ...more
Ricardo Signes
Feb 27, 2019 rated it it was ok
Shelves: sci-tech
It was fine. Maybe 15 years ago I would've found it useful. It didn't feel particularly insightful beyond widely-accepted doctrine. It was well constructed, and easy to skim, which I found myself doing as I went on. It was short.

It's been a long time since I read The Pragmatic Programmer, but I think I'd probably recommend that ahead of this.
Leandro López
Jul 01, 2019 rated it really liked it
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.
Adil Khashtamov
Oct 14, 2018 rated it really liked it
Short book about good practices on how to reduce code complexity
Mar 03, 2019 rated it it was amazing
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 chec ...more
« previous 1 3 4 5 6 7 8 next »
There are no discussion topics on this book yet. Be the first to start one »

Goodreads is hiring!

If you like books and love to build cool products, we may be looking for you.
Learn more »

News & Interviews

New kids on the writing block? Not a problem for young adult publishing, which is always on the lookout for hit first-time writers and...
82 likes · 33 comments
“Your job as a developer is not just to create code that you can work with easily, but to create code that others can also work with easily.” 2 likes
“Almost every software development organization has at least one developer who takes tactical programming to the extreme: a tactical tornado. The tactical tornado is a prolific programmer who pumps out code far faster than others but works in a totally tactical fashion. When it comes to implementing a quick feature, nobody gets it done faster than the tactical tornado. In some organizations, management treats tactical tornadoes as heroes. However, tactical tornadoes leave behind a wake of destruction. They are rarely considered heroes by the engineers who must work with their code in the future. Typically, other engineers must clean up the messes left behind by the tactical tornado, which makes it appear that those engineers (who are the real heroes) are making slower progress than the tactical tornado.” 1 likes
More quotes…