5 ms·

A Philosophy of Software Design. Very well-written. At 190 pages, quite likely finish-able in a weekend. But if you get 70% of the way through it, that is stil

A Philosophy of Software Design. Very well-written. At 190 pages, quite likely finish-able in a weekend. But if you get 70% of the way through it, that is still very valuable. It makes sense as an underlying set of principles that explain why you would use design patterns.

numbsafari 6y ago
This is a great book. Highly recommended for inclusion in a “thin” bookshelf.
shoulderfake 6y ago
An absolute must have I agree, amazing book.
code_biologist 6y ago
I came into this thread hoping to find the suggestion near the top. Beyond his credibility as the creator of Tcl, in the talk he gave at Google about the book [1] he describes the course he teaches that was the inspiration for the book. The course is to write a word processor with a team and extended it with features over the semester, swapping codebases between teams so occasionally you have to work with other's code. Essentially the largest possible code project you can fit in one semester. Along the way, Ousterhout will give a deep code review of the each project. I think it must be very insightful to see the same project implemented so many ways, and to see what works in terms of simplicity and extensibility. [1] https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY
diab0lic 6y ago
I came here to recommend this one, very digestible and has had a significant impact on the quality of the software I write.
gregfjohnson 6y ago
This book brilliantly illuminates the deepest issues at the core of software development. It is a well-written, gentle read. I have been programming for close to 50 years now, and this is probably the best and most insightful book I have ever read on software development. Its deceptive simplicity is such that a first-year programmer would benefit from it. Read it once per decade! You will get more out of it each time as you mature as a developer.
mannanj 6y ago
I see only positive reviews for this book here, but I went to look it up on amazon and the first review doesn't look particularly good and I'm looking for anyones reason to refute this: "This book does not consider functional programming, or the fact that terrible software in modern times is often the result of layers of incorrect abstraction that are often induced by the overuse of "object oriented" (OO) programming techniques. Instead, it takes OO programming for granted as being a good thing (visible in its preferences for two OO languages, C++ and Java), and then it reasons in that domain, making it totally uninteresting to many potential readers. The book also assumes that formal design doesn't work (he calls it "waterfall"), and takes alternatives for granted. I doubt the author is even aware of his inherent bias, but it is incredibly strong." Does anyone here agree or disagree with these points?
- jwdunne 6y ago
  Hrm, I read the book and the code samples were in mainstream languages, naturally, but there wasn’t a specific reference to OO. Algorithms by Sedgewick had more reference to OO but we don’t say that book is overly biased towards OO. The text isn’t about implementation or paradigm. It’s about things applicable in software design in general. For example, good interfaces are deep, rather than shallow. The examples of narrow interfaces are in Java because they were good examples. If you have to instantiate 5, 6 objects to use an interface, the interface is not deep. But if you had to do the same thing in a CLI interface or a GUI, it’s the same idea. You could apply the same ideas to functional APIs.
- floppy-disk 6y ago
  I would not agree that the bias towards OOP is a problem in the book, since most of the concepts are paradigm-agnostic. Nevertheless, I feel that the author exposes a rather opinionated (sometimes even dogmatic) and narrow view of software design. Although I think that the book provides a lot of very valuable insights, I missed a more differentiated view of the concepts presented in the book. For example, in chapter 4 ("Modules should be deep") Ousterhout dismisses the use of small classes and methods. He argues that using many small classes and methods makes the system as a whole more complex because many little pieces have to be managed. I completely agree with that statement. But only under the assumption that software systems are static and never-changing. If we consider software systems as ever-changing, I would argue that using smaller pieces often provides the flexibility necessary for maintaining large systems.
nickbauman 6y ago
I don't find design patterns very compelling unless you're stuck with underpowered statically-typed languages like Java. There, they serve somewhat as a way out of the straight jacket. In more powerful languages there are better, simpler ways to design your systems.

numbsafari 6y ago

This is a great book. Highly recommended for inclusion in a “thin” bookshelf.

shoulderfake 6y ago

An absolute must have I agree, amazing book.

code_biologist 6y ago

I came into this thread hoping to find the suggestion near the top. Beyond his credibility as the creator of Tcl, in the talk he gave at Google about the book [1] he describes the course he teaches that was the inspiration for the book. The course is to write a word processor with a team and extended it with features over the semester, swapping codebases between teams so occasionally you have to work with other's code. Essentially the largest possible code project you can fit in one semester. Along the way, Ousterhout will give a deep code review of the each project. I think it must be very insightful to see the same project implemented so many ways, and to see what works in terms of simplicity and extensibility. [1] https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY

diab0lic 6y ago

I came here to recommend this one, very digestible and has had a significant impact on the quality of the software I write.

gregfjohnson 6y ago

This book brilliantly illuminates the deepest issues at the core of software development. It is a well-written, gentle read. I have been programming for close to 50 years now, and this is probably the best and most insightful book I have ever read on software development. Its deceptive simplicity is such that a first-year programmer would benefit from it. Read it once per decade! You will get more out of it each time as you mature as a developer.

mannanj 6y ago

I see only positive reviews for this book here, but I went to look it up on amazon and the first review doesn't look particularly good and I'm looking for anyones reason to refute this: "This book does not consider functional programming, or the fact that terrible software in modern times is often the result of layers of incorrect abstraction that are often induced by the overuse of "object oriented" (OO) programming techniques. Instead, it takes OO programming for granted as being a good thing (visible in its preferences for two OO languages, C++ and Java), and then it reasons in that domain, making it totally uninteresting to many potential readers. The book also assumes that formal design doesn't work (he calls it "waterfall"), and takes alternatives for granted. I doubt the author is even aware of his inherent bias, but it is incredibly strong." Does anyone here agree or disagree with these points?

jwdunne 6y ago
Hrm, I read the book and the code samples were in mainstream languages, naturally, but there wasn’t a specific reference to OO. Algorithms by Sedgewick had more reference to OO but we don’t say that book is overly biased towards OO. The text isn’t about implementation or paradigm. It’s about things applicable in software design in general. For example, good interfaces are deep, rather than shallow. The examples of narrow interfaces are in Java because they were good examples. If you have to instantiate 5, 6 objects to use an interface, the interface is not deep. But if you had to do the same thing in a CLI interface or a GUI, it’s the same idea. You could apply the same ideas to functional APIs.
floppy-disk 6y ago
I would not agree that the bias towards OOP is a problem in the book, since most of the concepts are paradigm-agnostic. Nevertheless, I feel that the author exposes a rather opinionated (sometimes even dogmatic) and narrow view of software design. Although I think that the book provides a lot of very valuable insights, I missed a more differentiated view of the concepts presented in the book. For example, in chapter 4 ("Modules should be deep") Ousterhout dismisses the use of small classes and methods. He argues that using many small classes and methods makes the system as a whole more complex because many little pieces have to be managed. I completely agree with that statement. But only under the assumption that software systems are static and never-changing. If we consider software systems as ever-changing, I would argue that using smaller pieces often provides the flexibility necessary for maintaining large systems.

nickbauman 6y ago

I don't find design patterns very compelling unless you're stuck with underpowered statically-typed languages like Java. There, they serve somewhat as a way out of the straight jacket. In more powerful languages there are better, simpler ways to design your systems.