126 books
—
8 voters
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
by
Get A Copy
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
![Clean Code by Robert C. Martin](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="98" height="126"><rect fill-opacity="0"/></svg> "Clean Code by Robert C. Martin")
![Refactoring by Martin Fowler](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="98" height="125"><rect fill-opacity="0"/></svg> "Refactoring by Martin Fowler")
Community Reviews
Showing 1-30
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="50" height="66"><rect fill-opacity="0"/></svg>){kind=icon}
Start your review of A Philosophy of Software Design
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 ...more
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 ...more
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. ...more
The second half of the book is not so great. The emphasis on code comments goes against the idea of Clean Code. ...more
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 ...more
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 ...more
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)
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)
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
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 ...more
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 ...more
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. ...more
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. ...more
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. ...more
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. ...more
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: ...more
Linus Torvalds, on the beauty of programming: ...more
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
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
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
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!
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
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 ...more
Some concepts are not new and I have read it somewhere else. Some new conce ...more
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
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
This review has been hidden because it contains spoilers. To view it,
click here.
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 ...more
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 ...more
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 ...more
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 ...more
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 ...more
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 ...more
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 ...more
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 ...more
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 ...more
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 ...more
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 ...more
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 ...more
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.
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.
Feb 25, 2019
Dmitriy Rozhkov
added it
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
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. ...more
It's been a long time since I read The Pragmatic Programmer, but I think I'd probably recommend that ahead of this. ...more
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.
Short book about good practices on how to reduce code complexity
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
There are no discussion topics on this book yet.
Be the first to start one »
Readers also enjoyed
Goodreads is hiring!
123 users
82 users
65 users
52 users
39 users
32 users
16 users
15 users
13 users
12 users
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
No trivia or quizzes yet. Add some now »
“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…
