Fifty Seven. A Philosophy of Software Design by John Ousterhout
2018, Yaknyam Press, 190 pages. Written in English, read in English.
(Medium are making me clarify issues regarding possible affiliate links in my articles so please read this.)
Disclaimer: This is another professional book. It includes a lot of examples in C++ and Java, reading through which provides a lot of benefit in understanding the issues discussed, so I wouldn’t recommend it to the casual reader. But for software engineers, I wholeheartedly recommend it.
John Ousterhout’s book, A Philosophy of Software Design, revolves mostly around complexity and how to avoid it. But it is not the complexity we are used to reading about — having to do with long methods filled with multiple hierarchies of conditionals — it is the complexity of larger systems, that is based on how the different components communicate with each other, and how all of these components, as source code, communicate with future versions of the authors themselves, and with other contributors and maintainers down the line. Ousterhout, in fact, take a contrasted view to those espoused by many of the writers of other classics of software design — claiming that the most important aspects of software design are ease of expansion, triaging and refactoring; and readability — both attributes that can be achieved by breaking many of the myths of clean code. Ousterhout argues for a lot of comments, for example. He preaches for extensive comments at two abstraction layers — at the interface level, and at the implementation level, so that a potential reader does not have to go into the actual code to understand what the piece of software is doing. He argues for longer methods and classes, if those mean that the functionality of the class is better understood.
While the majority of the book is dedicated to different aspects of how to track complexity in software, and how to avoid it, Ousterhout spends the final three chapters on subjects unrelated to the main theme of the book — performance, design patterns and popular architectures, and while these also have interesting and useful advice on how to improve the quality of the software we write, they seem to have been haphazardly added to the book, and may have benefited from a whole book of their own.
At the end, Ousterhout provides two very handy indices of all of the attributes of complexity reduction that were discussed in the book, and all of the red flags indicating that the software we write is becoming too complex — both of which can be used as checklists while attempting to improve our code, based on what we’ve learned.
