If you’re lucky, once in a while something connects with you in a fundamental way.
I’m lucky enough to have had the pleasure of having two things fundamentally connect with me in the last two years.
Firstly, I read Team Topologies and realised we had been organising ourselves wrong for too long. The frustration that I had felt as an engineer and leader had not been imagined; it was founded on outdated management principles that, to this day, inhibit our industry.
Secondly, I discovered the work of Barry O’Reilly. A lone voice, in so much as I can make out, who tells us that we’ve been doing software architecture wrong all this time. Again this was something I suspected and felt deeply but had no real evidence for other than my interactions for the most part with enterprise architects and my firm belief that whatever happened, I didn’t want to become one. I believe that the existence of the role is nothing more than a distraction to the needs and wants of those who build real systems.
After a few decades of framework heavy, ivory tower approaches the value of Software Architecture is increasingly being questioned. In this book a new approach is defined that fuses Software Engineering, Complexity Science, and Philosophy to produce an entirely new way to think about how to design software.
Barry O’Reilly
Despite watching Barry’s talks about Residuality Theory and even attending his course on The Philosophy of Software Architecture, I still felt that something was missing. Although I could at this point in some small way explain what Residuality Theory was it had little practical purpose for me as yet.
But now, with the appearance of the book “Residues: Time, Uncertainty and Change in Software Architecture” there is now something that we can point to and say “read this, it will help”. Coming in at just 45 pages (at time of writing) it’s not a long book but it’s one that will help you think about what software architecture is and what it means in 2024.
This book won’t directly help you build your next system explicitly, but it will let you know that it’s absolutely normal not to get anything right first, second, third or even fourth time and it will make you think hard about what parts of your architectural choices will survive your choices. It will let you know however that there are some things which will work and some things that won’t.
The goal of the architect is criticality, not correctness. Correctness is the goal of the programmer and the mathematician. This is one of the first major lessons a becoming architect must learn.
Barry O’Reilly
Barry O’Reilly’s Residues: Time, Change and Uncertainty in Software Architecture is available on LeanPub.