"A Philosophy of Software Design" by John Ousterhout

This post is part of my Book reviews series, where I share thoughts and impressions on the books I read.

"A Philosophy of Software Design" is authored by John Ousterhout and published by Yaknyam Press.

💡Topic

Dealing with complexity in software design. Complexity is the main cause which makes systems hard to build, hard to maintain and hard to debug when they crash. 

📖Content

During 22 Chapters and 176 pages, John is guiding you through the root causes of complexity in his view, such as dependency and obscurity. 

He also showcases "red flags" that are an indication of unnecessary complexity, like information leakage, unneeded error conditions or overly generic names. 

And then he presents general ideas that all developers can deploy to create simpler and easier to understand systems, such as avoiding shallow classes, defining errors out of existence and separating interface documentation from implementation documentation.  

Code is presented as well, in either C or Java. 

👩‍💻🧑‍💻 Who is this book for?

The experienced developer, who's already gotten a few years of writing code daily.

You need a certain level of expertise and "battle scars" in order to grasp some of the points that John is making, and also their value.

👍Likes

His view on making heavy use of comments in the code to describe abstractions and things that are not easily visible from the code struck a chord with me, and I'll try out in my next projects some of his advice. 

Each chapter is short and to the point, like the entire book. 

One can definitely feel that the author has refined wording down to its bare minimum, probably in the same way that he's doing when designing his code. 

John shows a keen understanding of the tradeoffs that are involved in designing good software systems, including the fact that it takes more time and efforts to come up with a good design. 

Especially in the startup world, this means most often that very little time is spent on system design, as the current mantra is "tech debt is a privilege" and most entrepreneurs and CTO want to "move fast and break s#*%".

I am partial to his view that this sort of attitude leads to higher costs of development, more brittle systems, and overall worse experience both for developers as well as for users. 

The examples provided are quite good and are showcasing the points made quite well, with some caveats (see next section).

👎Dislikes

The examples also tend to be quite heavy though, and hard to understand in places. 

The author himself acknowledges this, and even actively asks for help in the Preface for showcasing better examples.

🚧 Improvements I would suggest

Better and more varied examples, ideally in other more popular languages as well e.g. Python or JavaScript. 

In a future edition I  would also like to see some more content around the concept of "composition vs. inheritance", as well as how to do good code reviews in a team.  

🤔Final Thoughts

The reader might not like some of John's opinions, e.g he's not a fan of TDD, believes that "agile development" leads to too much "tactical programming" and he advises the reader not to rely too much on established "design patterns". 

But I found those to be actually very interesting, and his arguments are solid.

A great read overall, with very solid advice.

I only wished the book would have been at least a few chapters longer!