Book Review: Residuality
I just stumbled on Barry O’Reilly presentation about Redisuality on Youtube and the concept he presented got me intrigued. I bought the book to complete my understanding of what he brings back from his foray in chaos theory to help solve software architecture problems. As I said in my initial installment, I really think that discrete software applications paradigm, as envisionned by hardware engineers and pushed by software companies like Microsoft for the past 4 decades, has reached his useful life. So my issues are not just with software architecture being flawed, but with creating and building software as a product as a whole concept.
To my surprise, he’s one of the few acknowledging in its introduction that we’ve taken too much from other engineering disciplines, trying to mold the immature software industry into another brach of engineering. He describes many of the problems I experienced and present, but comes with a somewhat limited but applicable solution: improve the way we do architecture.
I would quickly summarized his approach as TDD for architecture as, like TTD, you create a naive solution and gradually improve it as you create more and more test cases, letting your software grow organically as your tests improve. In his residue approach, you create a naive architecture, resulting from trying to solve a problem that was most probably wrongly expressed by users and other stakeholders. You then apply stressors (which could be seen as edge test-cases) and systematically assess how you architecture handle them and if not, produce a residual architecture and continue with like this until you reach a certain equilibrium.
For me, this is great if you continue to create classic discrete software proucts. I am one to question even the need for architecture as it forces us to freeze knowledge about the problem, which is more and more complex as our solutions span multiple organizations. It is very hard to create a snapshot of an ecosystem and create durable solutions. The nature of an ecosystem is to evolve, so any snapshot is like an anchor preventing its members from evolving, at least slowing them down. Just look at any committee standards orindustry protocols, they stay for decades and become baseline from which most innovative members diverge to get an edge over the others.
O’Reilly questions everything like the approximation of the knowledge on which we base our solution, the number of unknown stressors that will disrupt it, but never questions the need to create an architecture to solve problems in the first place. What if we could apply chaos theory to let software solutions emerge and evolve based on interactions between actors and processes? What if we didn’t have to apply chaos theory to improve an orderly construct like architecture or software, but let chaos forces the emergence of certain orderly relationships, between humans, objects, AI, systems or organizations? The resulting solution might not be the most efficient every time, but will ultimately tends toward efficiency, evolution or destruction, as actors move away towards new relationships.
To achieve this, we need to change our conception of software, from an offline construct inherited decades ago by hardware engineers living in a very different world, to an online and fluid one, designed for each an individual actors, unique, with patterns emerging as we need them. Our industry would be much more aligned to help actors realize their computing potential than to build new frameworks, tools or architecture methodologies for forcefully align our misaligned software model to our modern world.
