A Philosophy of Software Design
Excellent guide for the seasoned developer or architect
John Ousterhout
How to decompose complex software systems into modules (such as classes and methods) that can be implemented relatively independently
This book discusses how to decompose complex software systems into modules that can be implemented relatively independently. The discussion first begins with a fundamental problem in software design, managing complexity. It then discusses philosophical issues about how to approach the software design process, and it presents a collection of design principles to apply during software design.
The book also introduces a set of red flags that identify design problems. You can apply the ideas in this book to minimize the complexity of large software systems so that you can write software more quickly and cheaply.
Why I read this book?
I'm currently engaged in developing a prototype of what is going to be an extremely large software application, which tackles a multitude of complex tasks and issues. I am Single Developer/Architect on this project, which in itself is a daunting prospect, let alone that a number problems we're tackling on the project are relatively new fields to me such as, Deep Learning and Artificial Intelligence, which requires a lot of learning and research.
Despite this, the critical issue in any software project is always how to successfully manage the complexity going forward. In the particular project I am architecting there are a lot of moving parts, integrations and complex workflows that need to be addressed, this can often result in spinning out of control quickly. To add to this, we haven't completely identified all of the issues we will confront. In essence, we still have to discover the Unknown Unknowns as we cautiously proceed.
The temptation for any software developer is just to dive in and start coding: load up with caffeine put on the headphones and don't stop till we get something going.
I have to be honest, that is exactly how I approached this problem initially. However, I quickly realised that with this particular challenge, that despite how many lines of code I bashed out and irrespective of how many cups of Hot Lava Java I consumed the problems just kept getting bigger and more complex.
What I learned this book
Despite this book being relatively short compared to most of the books I have on anything software development related, clocking in at a mere 176 pages it is actually packed with some really useful insights, tips, strategies and lessons learned.
The thing I really got to respect from this book is that irrespective of what it is, everything you develop in software development, it has to be considered a Module. I especially appreciate the definition in Chapter 4: Modules Should be Deep
A software system is decomposed into a collection of modules that are relatively independent. Modules can take many forms, such as classes, subsystems or services
John Ousterhout - A Philosophy of Software Design
This phrase in itself made me start to think more deeply about the specific components, services and features of the specific application I'm designing, There are a number interaction points between specific areas and the temptation to think about these areas as just part of the application, when in fact these are just actually discrete applications in their own right and need to be designed and developed as such.
That being said, we have to be wary of Classitis a term I have come to appreciate and can relate too, as I have worked on many software systems in the past that actually have this issue. I particularly like the way the author challenges conventional thinking within software industry and highlights the inefficiency in this thinking.
It is also at this point in the book when we are first introduced to the author's concept of Red Flags, which are an extremely useful, informative and contemplative reference points.
What I like about this book
The primary focus of the book is about attempting to eliminate or at least reduce complexity in software. This can be achieved by taking more time and consideration in the design and thinking about the implications of design. Also by constantly reviewing design decisions.
As developers, we ultimately owe to ourselves to ensure we reduce complexity. The by-product of reducing complexity for ourselves is that we develop better products for our users.
I particularly enjoyed Chapters 5, 6, 7, 8 and 9 of this book, as the author walks through some examples of projects and discusses some of the issues and complexities found in them, and what can be achieved by reviewing some of the design decisions.
In many ways this book builds on and provides a lot of the background and philosophical points to issues raised in Java by Comparison
Pull Complexity Downwards
The chapter I most appreciated was chapter 8 - Pull Complexity Downwards.
It is more important for a module to have a simple interface than a simple implementation.
The chapter is by far the shortest chapter in the book, but it is also probably the most thought provoking. You might think this is ironic, but once you understand the basis of the chapter, one can only deduce that this is exactly what the author meant!
The simplest chapter abstracting the deeper complexities of what it means! I also absolutely love the conclusion of this chapter which states.
When developing a module, look for opportunities to take a little bit of extra suffering upon yourself in order to reduce the suffering of your users.
Why I recommend this book
In my opinion, this book makes a perfect companion read to Clean Code: A Handbook of Agile Software Craftsmanship. I felt the author makes some pretty strong and comprehensive arguments, as well as providing some really thought-provoking insights.
Clean Code
A Handbook of Agile Software Craftsmanship
software developers irrespective of programming language or discipline should read this book
What makes it especially great from a software related book, is that there is really not a lot of code to read and for what there is, it is just to relay an idea. Everything that is discussed in the book is at a fairly general and high-level, but it's still very helpful.
The author emphasises the benefits of trying to stay in Technical Credit rather than Technical Debt. There is also a refreshing absence of fashionable methodologies.
The book is also quite small and light which makes a great read for your daily commutes.
- What is this Directory.Packages.props file all about? - January 25, 2024
- How to add Tailwind CSS to Blazor website - November 20, 2023
- How to deploy a Blazor site to Netlify - November 17, 2023