“Philosophy of software design” book review

“Philosophy of software design” by John Oousterhout is not a new book. Both in terms of its publication (2018 and 2nd print in 2021), and my awareness of its existence. I saw recommendations from multiple people, that this is a “must read” book. Is it? Here is my opinion on that matter.

Software design – what is it anyway?

The question presented above it’s not a joke! The author fails to provide the definition of it. Yup, you’ve read that right. We got a book about software design, which is nowhere to be defined. 

Ok, I will actually reverse the typical book review structure here. I will start with a simple statement – yes, you should definitely read this book! Period. If you’re a TL;DR kind of reader – you can stop now. For those who want to get into things, bear with me for a minute.

What does John Ousterhout know about software design?

This is another valid question, but this time we actually get an answer. Here’s a direct quote from the book, that explains the rationale behind it, and who the author is:

I have now taught the software design class several times, and this book is based on the design principles that emerged from the class.

[..]

At this point you may well be wondering: what makes me think I know all the answers about software design? To be honest, I don’t. There were no classes on software design when I learned to program, and I never had a mentor to teach me design principles. At the time I learned to program, code reviews were virtually nonexistent. My ideas about software design come from personal experience writing and reading code. Over my career I have written about 250,000 lines of code in a variety of languages.

[..]

I don’t expect this book to be the final word on software design; I’m sure there are valuable techniques that I’ve missed, and some of my suggestions may turn out to be bad ideas in the long run. However, I hope that the book will start a conversation about software design. Compare the ideas in this book with your own experiences and decide for yourself whether the approaches described here really do reduce software complexity. This book is an opinion piece, so some readers will disagree with some of my suggestions. If you do disagree, try to understand why.

I’ve allowed myself to paste the above quotes in order for the reader to get a wider context of the book. Its purpose is to spark discussion, and confront your beliefs about how the software should be designed. 

I must admit that the book achieves its goal. Truth to be told – during the lecture, I had only two types of reactions. Hell no! And yes, I agree 150%. However, contrary to the “Clean code”, I didn’t get that much (although it is still there) vibe that says “that’s the only legit way of doing things”. Rules/suggestions presented by the author are still opinionated, and I think it is unavoidable in any domain that is as vague as software design (or architecture). In my opinion – that’s why you should read this book. To make your own judgment. The book is not even 200 pages long, it’s a quick read, so the goal is simple.

What I don’t like about “Philosophy of Software Design”?

Here is the part I should actually start my review with. I thought that there’s no point in going through every notion I don’t agree with. Gergely did that quite extensively already. What I want to point out here, is what I see as huge issues that haunt this book. In my opinion, those issues form the foundation of the author’s beliefs, and therefore if you don’t agree with any particular part of the book – it’s probably caused by one of the below.

We’re not living in 2005 anymore – technical part

As I started reading the book, I was struck by the “crudeness” (if that’s the word I can use here). Examples (in Java) provided by the author, are built around low-level code for opening and reading the file. I agree that the code presented is a part of Java’s STL. However, I can’t recall correctly, when was the last time I actually had to use it, or saw that kind of programming style in the projects I worked on. Wrappers around input streams in Java have existed since version 7 or 8, and they were released 10 or more years ago (4 years before the 1st edition was published).

My assumption here is that the author just stopped coding professionally at some point. It’s just a guess, but possibly backed up by the fact that the Stanford course he’s teaching (and uses extensively through the book) had its first edition in 2014. I was there Gandalf… Software creation in 2014 looked completely different than it looks today. Docker/Kubernetes were just born, cloud was there, but not that widely adopted. Same can be said about CI/CD. Languages and compilers still had a long way to go, and frameworks/libraries weren’t what they’re today. I wonder how the author’s opinions would change, if he was exposed to modern CI/CD cloud-based, microservices-architecture based projects. 

Those are code-based examples, but there’s more. In the second part of the book – concentrating more about readability of the code – I got a feeling like the author is still using VIM or Emacs from 1995, on a 14-inch EGA monitor to do any coding. The remarks about how to structure the code, or the purpose of the comments – with the latest tools it’s really not a problem to see the Javadoc/comments or jump between methods. They’re just one shortcut/mouseclick away! It’s just a feeling I got, but it accompanied me through most of the lecture.

We’re not living in 2005 anymore – process part

This is also a feeling I got, but here, I can actually back it up by the direct quote (markings are mine). 

Designing it twice does not need to take a lot of extra time. For a smaller module such as a class, you may not need more than an hour or two to consider alternatives. This is a small amount of time compared to the days or weeks you will spend implementing the class.

Eeeehkhhm. How about no? If you’re working on some cutting-edge software then maybe. However, we must be honest here – how many developers actually do so? Whether we like it or not – I would argue, that circa 80% of the programming is maintenance, and new software is more like assembling the jigsaw puzzle, than creating everything from scratch. It’s not that I am against the idea of design-it-twice principle. I am referring here to the overall feeling I got, that the author stopped participating in the real-world projects for quite some time. And his view of things is influenced by that tremendously. 

Which leads us to the last thing that I had a problem with. Drum rolls please!

We got this tool for code quality now, and it’s called unit testing

Several chapters about designing interfaces. Deep vs shallow ones. Code naming, comments, navigation, readability. And yet nothing, seriously, nothing is being said about testing. Specifically code-oriented unit testing. It is mentioned shortly, in the chapter called “Software trends” (which seems to be out-of-place), but rather to indicate that the author knows it exists. I am biased here for sure, but I have been using unit-testing in the projects since circa 2013/2014 on a regular basis. What is more – they were always already there when I joined the project! I did not have to introduce unit-testing overall or convince the team to start writing them. It was just obvious that they are there. 

Having said that, it is obvious that my approach to software design and quality is unavoidably linked to the process of TDD. I would argue that a large portion of the book could be shortly summarized by saying – “just use TDD”. Naming, the separation of concerns, interface breadth – everything looks different when approached from the unit-testing perspective. What surprises me most, is that the author clearly wrote them in his projects. He mentions the huge test amount that was created for the TCL core engine, and that those tests allowed serious refactoring to occur. Why then there’s almost no mention of the tests in the chapters that just beg to have them – I don’t know.

Summary

It may seem like the above post was written for ranting only. Yes, I admit, had a bad night and did not get that much sleep. However, as I have stated at the beginning – “Philosophy of software design” is still a should-read book. Not as a reference docs to be applied everywhere, but as a beliefs-questioning and self-introspect tool. Although I think that it should be read by the readers, who are already seasoned devs. Giving it to the programmers without battle scars could prove fatal, if they start to put everything from the book into practice. Well, after giving it some thought – does it not apply to any book?