Blog
Reboot: How Complexity Science Saves Architecture
Posted on 2026-11-09 - 4 minute read
Barry O'Reilly, software architect and PhD candidate in complexity science, used his DDD Europe talk to tackle a question he says he's asked constantly: where do you even start with complexity science? His answer took the room through the whole history of software architecture, and arrived at a deliberately provocative claim: software is not complex. It just needs to be treated properly.
Key takeaways
Architecture has cycled through three phases, and we've run out of new ideas. O'Reilly traced the profession from Turing's 1936 work on computable numbers, through Dijkstra's structured programming in the 1960s, to Lehman's adaptive, Darwinian view of software from the 1970s. Every phase was a reaction to the same problem: uncertainty in the business environment. We've been recombining these three pillars, logic, structure, and adaptivity, ever since without producing anything genuinely new.
Complexity science has become a source of fancy words rather than better outcomes. Drawing on Ralph Stacy's idea of the "dominant discourse of management", O'Reilly argued that organisations absorb the language of complexity and systems thinking, then quietly revert to command and control. The result is that agile teams use complexity to justify constant iteration, and enterprise architects use it to justify boxes and lines. Nothing actually changes except the vocabulary.
Unpredictable does not mean complex. This was one of the talk's central corrections. A car can be unpredictable and still be a complicated system with a traceable fault. A double pendulum is deeply unpredictable but fully determined by its own physical properties. Software behaves the same way: it is shaped entirely by its hardware and the code written for it. Treating every surprise in production as evidence of complexity, O'Reilly argued, is a category error.
Software is complicated, not complex. This was the talk's headline claim. You should be able to analyse software's parts, understand its behaviour, and predict what happens when you press a button. If you can't, that's not because software is inherently complex; it's because something in the design has gone wrong. The environment software runs in, on the other hand, genuinely is complex, constantly shifting, and emergent.
Residuality theory puts the boundary between the complex and the complicated. O'Reilly's own contribution treats the architect's job as managing the relationship between a complicated system (the software) sitting inside a complex environment (the business context). Push that boundary all the way out and you get enterprise architecture, trying to reduce everything to structure. Pull it all the way in and you get an "uber agile" view where everything is complex and nothing can be isolated or controlled. Neither extreme is correct; they're just different boundaries with different consequences.
Isolation is a legitimate architectural tool, not a cop-out. O'Reilly compared this to an electrician working on a single switch and cable without needing to think about the entire national grid. Developers do this every day. Reducing scope and isolating a problem is how complicated systems get built and understood, and architects shouldn't feel guilty about not accounting for everything at once.
The real danger is coherence without correspondence. Because it's so hard to run controlled experiments on software projects, the industry tends to believe explanations that simply sound coherent, rather than ones that have been shown to actually work. O'Reilly called this vulnerability to "woo woo": impressive complexity vocabulary that changes nothing in practice, and risks discrediting the whole field once someone calls it out.
The one thing to try next
O'Reilly's closing challenge was simple to state and harder to sit with: work out where you currently set the boundary between what you treat as complicated and what you treat as complex, in your own architecture decisions. Ask whether you set that boundary deliberately, or whether it was set for you. Then ask what would change if you moved it.
What participants said
Amazing topic, Residuality Theory, with a compelling case for it. It gave me a lot to sit with afterwards.
Clear, and it made me think a lot. It's the type of talk that makes you wonder why there aren't more software philosophers like him. We should be more conscious of where we come from as a profession.
Great new insights into software architecture, particularly around setting the boundaries for architectures. I'd love to see more examples of how to bring this into practice.