Residues: Time, Change, and Uncertainty in Software Architecture., Barry M O’Reilly
I can't recall how I stumbled on the Residuality Theory conference talk, but in a lot of ways that was a more compelling intro than the book it spawned. That said, the ideas are interesting...
Criticism of the field of software
The history of software engineering thus far has been tantamount to nailing horseshoes to car tires.
He's certainly not pulling any punches. It's easy to point to the failures and a lot harder to do something about it.
Residuality as a concept
It's a challenge to grasp what is meant by the residue. The author leans heavily on one really good example but states that reviewing case studies isn't a good way to learn compared to the experience of just trying it. Ok, fair enough, most things are best learned through experience -- and I'm doing just that (look for a project post soon eventually). That is, however, a lot to ask of readers and for some unknown reason he goes even lighter on the one example in the book than the conference talk!
The method espoused, as best I understand it, is to iteratively throw darts (stressors) which affect the software in one way or another at a notional naive architecture and mentally simulate what breaks and what doesn't. Use this information to redesign the architecture to survive the stressors, and note the parts that remained working under those changes are the residues. After iterating enough, you're left with nothing but residues which can together accomplish the goals of the system! There's no need to handle every conceivable stressor but common-enough residues will handle many different stressors.
Similarity to Volatility-based decomposition
I think there's a strong relationship to Righting Software's Volatility-based decomposition, which is about decomposing systems according to what changes together. The author describes encapsulating these related areas of change like putting them in safes, any of which could have a hand grenade thrown in and get completely scrambled but leave the others intact. What is it with these architecture guys and the colorful analogies?
What's next for the field of software
I'm disinclined to talk about LLMs applied to software development - maybe I will write a post someday about my thoughts and just link it. In the meantime it suffices to say that there are still plenty of problems to solve and the architecture side of things is even less of a solved problem.
The author frequently contrasts writing software and especially software architecture with engineering - It's almost like the "more of an art than a science" trope. Some of the "comp sci" aspects have solutions which can be precisely specified and objectively evaluated. However, the "building software systems to work in a constantly-in-flux human context" (which the author terms Hyperliminal Systems) aspect is almost brand new. We've only had programmable general-purpose digital computers for ~80 years and we've only been building software systems as the default answer for handling all kinds of business problems for what, 30 years? Surely we've barely crossed the starting line for understanding how to build software in a long-term useful way.
I'm going to stake my career on there being, at the very least, human insight and direction needed to refine problems into useful systems.
The Architect's Paradox
Stay tuned for thoughts on the authors next book, The Architect's Paradox. It's a philosophical take on the field of software. Or maybe it's a software take on philosophy. Either way, it was thoroughly enjoyable.