I recently finished reading A Philosophy of Software Design by John Ousterhout and I thought that it would be useful to share my opinion about it with the community.
My motivation for picking up this book was that I saw that it is one of the best sellers in Amazon and it had a lot of good reviews.
The author of the book is John Ousterhout. He is a professor of computer science at Stanford University. He was a professor of computer science at the University of California, Berkeley where he created the Tcl scripting language and the Tk platform-independent widget toolkit and proposed the idea of co-scheduling. John Ousterhout has done some significant contributions to the field of computer science and has been awarded a Grace Murray Hopper Award and an ACM Software System Award.
This book was written by John Ousterhout to be used as the main reading material of one of the subjects in the computer science program at Stanford University. Despite the highly-academic background of the author and being part of the content of the computer science program at Stanford University, the book is written in a very colloquial style that can be followed with easy by non-academics and beginner computer science students.
I'm an experienced developer and I have heard about many of the ideas in the book before. However, I still enjoyed this book because I think the author has done a very good job extracting the essence of some concepts and putting it down in words. I particularly enjoyed the sections about complexity, interfaces and abstractions.
I also enjoyed that the author dares to challenge some common best practices such as "functions should be small" or "classes should only do one thing" because it encourages experimentation and being open-minded.
The book is divided into the following 21 chapters:
- The nature of complexity
- Working code isn't enough
- Modules should be deep
- Information hiding (and Leakage)
- General-purpose modules are deeper
- Different layers, different abstractions
- Pull complexity downwards
- Better together or better apart? 10 Define errors out of existence
- Design it twice
- Why write comments? The four excuses
- Comments should describe things that aren't obvious from the code
- Choosing names
- Write comments first
- Modifying existing code
- Code should be obvious
- Software trends
- Designing for performance
I really enjoyed the first half of the book. The first chapters discuss the nature and the main causes of complexity in software. The following chapters explore some common design problems in modules, interfaces, abstractions, coupling, and error handling. The book highlights the main problems as a list of red flags that we should avoid. I disliked that some of the ideas felt somehow opinionated and not really objective. However, I didn't have a big problem with it because I actually agree with most of the points of view of the author. Also, he would not be able to challenge some common best practices without being opinionated.
After chapter 11 the content was less appealing to me because I felt that I wasn't learning as much as I was learning during the first half of the book. However, this is probably my case because I have read other books (e.g. Clean Code) on similar topics.
I would recommend the book for both senior and junior developers because I really enjoyed the first half of the book and I assume that some less experienced developers will find the second half of the book more interesting than I did.
I would also like to mention that this book is reasonably cheap. Many tech books have a price mark of 40 to 60 USD and this books available for 17.27 USD in its paperback edition. Unfortunately, the book is not available in digital formats.
I hope you have found this review useful. I have plans to try to review all the tech books that I read from now own. So please follow me if you want to read more book reviews in the future. Also, if you are interested in Functional Programming or TypeScript, please check out my upcoming book Hands-On Functional Programming with TypeScript.