What do you think?
Rate this book
A Philosophy of Software Design
This book addresses the topic of software design: how to decompose complex software systems into modules (such as classes and methods) that can be implemented relatively independently. The book first introduces the fundamental problem in software design, which is managing complexity. It then discusses philosophical issues about how to approach the software design process, and it presents a collection of design principles to apply during software design. The book also introduces a set of red flags that identify design problems. You can apply the ideas in this book to minimize the complexity of large software systems, so that you can write software more quickly and cheaply.
179 pages, Kindle Edition
First published January 1, 2018
1,851 people are currently reading
11.4k people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 476 reviews
August 14, 2018
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.
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.
March 5, 2019
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.
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.
September 24, 2018
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.
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.
August 18, 2020
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:
-
-
-
-
-
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! ;)
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:
-
-
-
-
-
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! ;)
November 21, 2021
I read this book as it was 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:
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:
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:
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.
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.
September 1, 2019
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.
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.
October 27, 2018
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.
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.
January 20, 2019
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)
January 17, 2022
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.
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.
October 2, 2018
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.
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.
June 6, 2021
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."
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."
September 5, 2018
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.
August 5, 2019
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.
February 26, 2025
As far as these books go, this one is fine. It is also quite brief. The arguments seemed reasonable—I didn't find too much to disagree with (aside from some caveats). The whole book is surprisingly non-dogmatic.
The caveats:
I don't place much value on abstraction as defined in the book (which is basically wrapping a pile of shit well enough so that its smell is almost imperceptible.) When working with pretty much any library or tool, I inevitably end up reaching for the internals at some point, because someone decided to make something private. It's especially annoying to have to fork when there's no escape hatch.
Regarding comments, the author greatly overestimates both programmers' willingness and ability to write texts that anyone would actually want to read and their vocabulary. We aren't Hemingways.
In general, the whole genre of books on best coding practices is basically socially acceptable masturbation. The average Joe in the industry a) has no authority to practice "strategic programming" b) isn't even going to be there in two years, so they won't feel the consequences of their choices anyway. At least it's unlikely that APoSD will do as much damage as Clean Code did.
The caveats:
I don't place much value on abstraction as defined in the book (which is basically wrapping a pile of shit well enough so that its smell is almost imperceptible.) When working with pretty much any library or tool, I inevitably end up reaching for the internals at some point, because someone decided to make something private. It's especially annoying to have to fork when there's no escape hatch.
Regarding comments, the author greatly overestimates both programmers' willingness and ability to write texts that anyone would actually want to read and their vocabulary. We aren't Hemingways.
In general, the whole genre of books on best coding practices is basically socially acceptable masturbation. The average Joe in the industry a) has no authority to practice "strategic programming" b) isn't even going to be there in two years, so they won't feel the consequences of their choices anyway. At least it's unlikely that APoSD will do as much damage as Clean Code did.
March 15, 2019
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.
Very uneven book. Hence the rating which is somewhere in between (3 stars) great & mediocre.
September 23, 2018
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.
Read
February 25, 2019I'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.
August 19, 2021
This is a good compilation of lessons in building good software, likely many of which you've heard under other, idiosyncratic names in the occasional Hacker News post. The author's put names on a few things I watch out for, but never put a name to. Nothing remarkable, but an easy, nice read that's a good refresher for anyone who writes software.
January 29, 2025
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.
- 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.
June 24, 2021
Perełka wśród książek o tym jak pisać czysty kod i zarządzać złożonością oprogramowania. Czym wyróżnia się na tle swojego najpopularniejszego konkurenta? Przystępnością, zwięzłością i doborem przykładów. Niektóre opinie autora stoją w całkowitej opozycji do praktyk rekomendowanych przez Uncle Boba: krytyka krótkich metod, konieczność pisania dużej ilości komentarzy. Mimo że nie przekonały mnie do zmiany nawyków, argumenty Ousterhouta w tych kwestiach były dobrze przemyślane i poszerzyły moją perspektywę.
December 6, 2019
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!
March 2, 2019
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 didn't give 5 stars: there is some amount of hand-waiving around why simplicity is the right measure, and some other justifications. And the book is very OOP-centered, suggesting that this is the best way to approach design, which is not necessarily the case.
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 didn't give 5 stars: there is some amount of hand-waiving around why simplicity is the right measure, and some other justifications. And the book is very OOP-centered, suggesting that this is the best way to approach design, which is not necessarily the case.
August 31, 2019
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.
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.
July 1, 2019
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.
October 14, 2018
Short book about good practices on how to reduce code complexity
January 2, 2020
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.
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.
June 2, 2020
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.
May 25, 2021
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.
June 5, 2023
Лучшая книга по дизайну того, как строить крупные программы. Закладывает правильное понимание к тому, как стоит писать код, что есть хорошо, а что плохо. И главное адекватное критикует популярные мнения типа "не больше трёх строк на функцию". В общем, must have для любого современного разработчика.
P.s. если не уверены хотите читать или нет, откройте последние две страницы и изучите принципы. Если зацепит, то читайте (:
P.s. если не уверены хотите читать или нет, откройте последние две страницы и изучите принципы. Если зацепит, то читайте (:
Read
December 29, 2024The red flags exposing complicated code mentioned throughout the book seems really useful, even though have not applied them yet. Recognise myself having designed modules in a temporal fashion (e.g. ETL pipelines) that likely design wise would have resulted in more information hiding.
Displaying 1 - 30 of 476 reviews
Can't find what you're looking for?
Get help and learn more about the design.