I’ve been reading long-form news seriously for a couple of years — global politics, economics, supply chains, how decisions in one country send ripples through systems thousands of miles away. At some point I noticed I was reading it the same way I debug code: looking for which assumption broke first, not just what the error message said.
That’s not an accident. The patterns are the same.
The Suez Canal as a distributed systems lesson
In March 2021, a container ship ran aground in the Suez Canal and blocked it for six days. The direct impact was obvious: ships couldn’t pass. What took weeks to fully surface was the depth of the dependency graph — which industries discovered they were waiting on which components, which products missed which delivery windows, which manufacturers halted production because of a single point of failure in a shipping route most of them had never consciously thought about as a dependency at all.
When I read about that at the time, I thought: this is exactly what a distributed system looks like when one service goes down and the on-call engineer discovers, in production, that everything was more tightly coupled than the architecture diagram suggested.
The failure wasn’t in the ship. It was in the assumption that the route was reliable enough not to need redundancy. It was in the implicit dependency that nobody wrote down because nobody thought to question it.
Complicated vs. complex — and why the difference matters
There’s a distinction in systems thinking between complicated and complex that I’ve found more useful than most software architecture frameworks.
A complicated system has many parts, but they’re knowable and predictable. A jet engine is complicated — many components, but if you understand each one and how they connect, you can reason about the whole thing. A complex system has emergent behaviour — outcomes that arise from interactions between components in ways that no individual component would produce alone, and that weren’t designed or anticipated.
Most production software systems, once they reach a certain size and have been touched by enough people over enough time, become complex rather than merely complicated. The failure modes aren’t in the parts you understand — they’re in the interactions between parts that were each understood in isolation.
I read about supply chain disruptions and economic shocks through exactly this lens. The events that cause cascading failures aren’t usually dramatic technical failures in critical components. They’re quiet, reasonable assumptions — this supplier is reliable, this route is stable, this library is maintained — that turn out to be single points of failure nobody documented.
What this means when I’m actually writing code
I’m not suggesting every junior developer should spend their evenings reading the Financial Times. The specific domain doesn’t matter.
What matters is developing a mental habit of asking: what does this depend on that I haven’t explicitly acknowledged? Not in a paranoid way that paralyses progress, but as a routine question during design.
When I’m designing an API, I ask: what downstream systems assume a specific response shape from this? When I’m adding a feature, I ask: what shared state does this modify that I’m not tracking? When I’m choosing a dependency, I ask: what happens to this codebase if this package stops being maintained in two years?
These questions aren’t technically sophisticated. The habit of asking them consistently, before problems surface, is harder than it sounds.
The skill nobody teaches
Most software education focuses on correctness within a bounded problem: given these inputs, produce this output. That’s necessary, but it’s not sufficient for building things that stay working in production over time.
The harder skill is reasoning about systems under conditions their designers didn’t anticipate — and recognising that your system, whatever it is, is part of a larger system with dependencies you haven’t mapped.
Global systems fail for exactly the same reason software systems fail: someone was treating a complex system as if it were merely complicated. The entities change. The pattern doesn’t.
If you want to build better software architecture intuition, reading about how other complex systems fail isn’t a distraction from the technical work. It’s a different angle on the same problem.