Survivable complexity is assembled, not authored
2026-07-21 · What Counts as Complex
You assume that "taking a system apart to analyse it" is the analyst's free choice — cut it fine or cut it coarse, as you like. It isn't. Whether a system can be cleanly taken apart is a property of the system, not of you; and that property is exactly what decided whether it could be evolved into existence in the first place, and whether it can be changed later without the whole thing coming down.
A watch has a thousand parts. Imagine two watchmakers making watches of equal precision and equal value — yet one grows rich and the other goes broke. The difference isn't skill. It's the order in which they put the parts together. That little story — told by Herbert Simon in 1962 — is the seed of this whole issue.
The question it answers is plain: why is nearly every complex system you meet — from cells to companies to operating systems — built as nested boxes within boxes? Coincidence, taste, or is there a harder reason forcing them into that shape, one they cannot survive without?
This issue and the last one (emergence) are a pair: emergence is about "the whole having properties the parts lack"; this issue is about how those wholes get built up, layer by layer, and taken apart again. Built up, and taken apart — those turn out to be two faces of the same thing, as we'll see.
Simon's parable runs like this. Two watchmakers, Hora and Tempus, each make watches of a thousand parts. Both are equally skilled and equally in demand — which is precisely the problem, because the phone keeps ringing with new orders.
Here's the catch: the watch on the bench isn't finished when the phone rings, and you must put it down to answer. And a half-assembled watch, set down, falls apart — as long as what you've built so far isn't a whole that can stand on its own, letting go collapses it back into a heap of parts.
Tempus adds parts one at a time; even at part 999 he still holds a heap that scatters the moment he lets go. So every ring of the phone sends him nearly back to the start. Hora does it differently: he builds stable sub-assemblies first — ten parts clicked into a small module that stands on its own, ten such modules into a larger one, ten of those into the finished watch. When the phone rings he loses, at most, the one sub-assembly he's currently on; every completed module stays intact.
Simon did the arithmetic: if the chance of interruption per part added is even one percent, the two men's efficiencies differ by orders of magnitude — Hora finishes comfortably, Tempus almost never completes a single watch. The whole gap comes from one thing: Hora's half-products are, at every stage, wholes that stand on their own.
Read that backwards and you get this issue's first hard conclusion: among complex systems that are built up step by step — whether by evolution or by engineering — only those with stable intermediate forms can actually get built. Complex systems without stable intermediate forms aren't forbidden; they're nearly impossible to reach, because every path to them scatters too easily en route. So everything around you is nested boxes not because layering is pretty, but because the un-layered ones never survived long enough for you to see them.
Now swing the camera from "how it gets built" to "what it looks like once built." Simon gave layered systems a more precise name: near-decomposable — almost, but not quite, separable.
The definition is two sentences, each needing care: interactions within a module are strong and fast; interactions between modules are weak and slow. Note "weak," not "absent" — with no connection at all you'd have several unrelated systems, not one system. The whole subtlety lives in that "near": connected, but loosely.
This strong/weak gap has a very practical consequence, which Simon stated crisply. His own example: a building, several rooms, walls between them that don't insulate perfectly. You light a stove in one room. Two things happen on sharply different timescales — in the short run, the air in each room quickly settles to its own temperature while barely any heat has yet crossed between rooms, so you can treat each room as an independent little system and solve it alone; in the long run, heat slowly seeps through the walls until all rooms drift toward one common temperature.
This is why you can study the parts of a complex system separately without being completely wrong: not because they're truly unrelated, but because over the span you care about, the coupling between modules is slow enough to treat as an unchanging background. It's also another way of stating last issue's "effective degrees of freedom" — near-decomposability is the physical precondition for that "effective layer" to have a description of its own.
Whether to split a system and handle the parts separately shouldn't be a gut call — measure its coupling timescales: how fast does a module settle internally, versus how fast do modules seep into each other? The bigger the gap in orders of magnitude, the safer it is to "solve apart," to parallelise, to outsource, to divide labour. When the two speeds are close — or reversed, external faster than internal — any split will deceive you, and the move is to map the coupling structure first, not to force a cut.
Since modules are loosely coupled, you can change one module without disturbing the others — swap the kitchen stove without rewiring the whole building. That sounds ordinary, but it's the entire source of evolvability and maintainability: in a near-decomposable system, the consequences of a change are trapped inside a module rather than running out along strong couplings.
And here hides the most common — and costliest — mistake: people draw module boundaries by "function" or by the org chart, while the system's real seams live in the coupling graph, and the two often don't coincide. The module you think you have need not be its actual module.
In 1972 the computer scientist David Parnas said it outright. The prevailing wisdom was to split software by "processing step" — read input, then sort, then output, one module per step. Parnas argued this was wrong: split instead by which design decisions are likely to change together, hiding each volatile decision inside a module (he called this "information hiding"), so interfaces stay stable and internals are swappable. In this issue's terms: the seam should be cut where coupling is weak, not where the flowchart is easy to draw. Cut wrong, and you think you've separated things while every change still yanks the whole web.
So "taking a system apart," done right, isn't: decide how many pieces, then hack it into that many. It's: see the coupling structure first, find the few bridges that were already thin, and cut along them. Natural seams are discovered, not decreed. Decreed boundaries the system doesn't honour.
Before splitting a system (code, org, process, plan), don't ask "how many pieces" — draw the "who-drags-whom-when-changed" graph first, and cut where the drag is least. A test you can run on the spot: imagine changing each candidate module and count how many things outside it get pulled in. Fewer pulls means you found a real seam; if every candidate drags a whole crowd, the pile simply isn't near-decomposable right now, and forcing a cut just hides the strong coupling where you can't see it.
Now the other side. Near-decomposability is an excellent lens, but there are three places it gets pushed too far, and you should mark the boundaries before you use it.
First, the "necessarily" in "complex systems are necessarily hierarchical" is inflated by survivorship. Strictly, Simon's argument shows only this: among complex systems that a stepwise, interruptible process can build, the layered ones dominate overwhelmingly. It does not show that non-hierarchical complex systems are logically impossible. A whole class of them has no clean seams at all — in physics, spin glasses and various frustrated systems, where every element couples strongly to a great many others, so any cut severs a mass of strong links. They're genuinely complex and genuinely real; they just can't be built up layer by layer like a watch. So the accurate statement is: hierarchy is not the definition of complexity — it's the entry fee paid by complexity that can be built up incrementally.
Second, seams drift, especially under stress. Near-decomposability is a fair-weather property. The cross-module links that are weak in calm times can strengthen together when the system is under pressure — in that block-diagonal matrix from the last section, the faint off-diagonal points darken all at once, and the three modules fuse into one indivisible block. In finance it's "correlations approach 1 in a crisis"; in engineering it's "a hidden shared dependency surfaces under load." Every division of labour, parallelisation, and isolation you built on the fair-weather seams fails at exactly the moment you most need it to hold.
Third, modularity itself has a cost; more is not better. Cutting requires interfaces, and interfaces have overhead and lose information; cut too fine and things that could have been jointly optimised are artificially walled apart, so you can no longer reach the global optimum. The "near" in near-decomposability has proportion — it says there exists a scale at which coupling is weak enough, not that finer is better. The real craft is finding the grain size that's just right, not mindless splitting.
Before judging with "near-decomposability," answer three things plainly: (1) is your system the kind that was built up stepwise? (yes → the hierarchy prior holds; no → don't assume it has seams); (2) will the weak couplings you rely on strengthen together under stress or crisis? (yes → don't base your contingency plan on the calm-weather boundaries); (3) is your grain too fine, walling apart things that should be jointly optimised? Fail these three and don't let modularity give you false confidence.
You can, but it matters whether you're discovering a seam or manufacturing one. Manufacturing a seam = deliberately severing some existing strong couplings and replacing them with controlled narrow interfaces (microservices, department walls, legal-entity isolation all do this). The cost is that the severed couplings were doing something useful; once cut, either you rebuild them through the interface (with overhead) or you genuinely lose them. So modularisation isn't free tidying — it's a trade of "joint-optimisation capacity" for "changeability," and you have to check whether the exchange rate is worth it.
They're two faces of one thing. Emergence says the high level has a self-contained description of its own (temperature, price); near-decomposability says why that description can be self-contained — because the low level is packaged into weakly-coupled modules, and the modules' internal detail settles into a background constant on the high level's timescale, so the high level need only track a few aggregates. Without near-decomposability there's no clean "effective layer," and emergence has nothing to stand on.
Because what's being changed is module boundaries, and boundaries are exactly where coupling is most tangled and history heaviest. A system runs near-decomposably in normal times because its current boundaries roughly align with the actual coupling; redraw the boundaries and you briefly manufacture a crowd of strong couplings that straddle the new lines (collaboration once inside one department must suddenly cross departments), so during the transition the system is less decomposable and more prone to scatter — isomorphic to Topic 10's "you must get worse before the tipping point."
An honest worry, and the place this method is most prone to self-deception. The test is to make "seam" make a falsifiable prediction: if you claim a spot is a weak-coupling natural seam, then after cutting along it the two sides should be able to change independently, neither triggering rework in the other. If every change to one side forces you back to fix the other, what you found isn't a seam — it's a cut you hoped was one. A seam's truth is judged by the knock-on consequences of change, not by how nice the diagram looks.