A short 1998 paper on why complex systems break has resurfaced in engineering discussions. It argues failure is normal, causes are never single, and operators are the ones holding fragile systems together.
Key takeaways
- “How Complex Systems Fail” is a short document, widely circulated online, that describes failure in high-hazard systems as a normal property of complexity rather than an aberration.
- Its central claim is that complex systems always contain latent faults, and that catastrophe requires several of them to align rather than one root cause to appear.
- The framework rejects “root cause” as an explanatory tool, treating it instead as a social and organisational device for closing an investigation.
- It reframes human operators as the adaptive element that keeps degraded systems running, which reverses the common assumption that people are the weak point.
- Readers can apply it practically by changing how incident reviews are written, how blame is assigned, and how safety margins are monitored during normal operation.
What is actually being discussed
The document in question is a brief set of numbered propositions about why complex, tightly coupled systems fail. It was written in the context of medical and other high-hazard domains, and it has since been adopted well beyond that origin — particularly by people who run software infrastructure, where the same conditions apply: many interacting components, continuous change, incomplete knowledge of the system’s actual state, and consequences that arrive faster than understanding.
The text is not a research paper in the conventional sense. It presents no dataset and offers no statistical argument. It is a compressed statement of a position, each point stated in a sentence or two and left to stand. That format is part of why it has travelled so far: it can be read in a few minutes and quoted a line at a time.
The core propositions, stated plainly, run roughly as follows. Complex systems are intrinsically hazardous, and they are defended against that hazard by layers of protection. Because those defences work, the systems run in a degraded mode almost all the time, carrying faults that have not yet combined into anything visible. Catastrophe therefore requires multiple failures to occur together; single-point failures are usually absorbed. Post-accident attribution of a “root cause” is fundamentally wrong, because it selects one contributing factor from many and calls it the explanation. Human practitioners operate the system and also create safety within it, constantly adjusting to keep it working, and their actions look like errors only in hindsight.
Why it is circulating again now
Documents of this kind resurface periodically rather than continuously. The immediate trigger for the current round of attention is a submission to a technology news aggregator that attracted substantial discussion, but the underlying reason is more durable: the ideas have become part of the working vocabulary of reliability engineering, and each new cohort of engineers encounters them for the first time.
There is also a structural reason. Software systems have grown steadily more distributed, more dependent on third-party services, and more automated in their deployment. Each of those trends increases the number of interacting components and reduces the degree to which any one person can hold the whole system in mind. Those are precisely the conditions the document describes. It is worth being clear about what is not known here: whether the current spike in attention reflects any particular incident, industry event, or anniversary is not something that can be established from the signal itself.
The background a newcomer needs
The document sits within a broader body of work usually described as safety science, or more specifically the study of resilience in high-hazard industries. That field emerged largely from investigations into aviation, nuclear power, chemical processing and healthcare — domains where accidents are rare but severe, and where the conventional engineering response of adding more procedures had visibly diminishing returns.
The older tradition in accident analysis treats an accident as a chain of events with an identifiable first link. Break the chain at any point and the accident does not happen; find the first link and you have found the cause. This model is intuitive and it underpins most regulatory and legal responses to failure.
The newer tradition, which this document belongs to, treats accidents as emergent. Failure arises from interactions between parts that are each functioning as designed. There is no first link, because the contributing conditions were present for a long time before the accident and continued to be present afterwards in systems that did not fail. The practical consequence is that you cannot prevent the next accident simply by fixing what broke in the last one.
A distinction worth carrying: complicated systems have many parts but predictable behaviour, and can be understood by taking them apart. Complex systems have behaviour that arises from interaction, and taking them apart destroys the thing you were trying to study. Most modern production infrastructure is complex in this second sense.
Who is affected and how
The most direct audience is anyone who operates a system where failure has consequences and where no single person understands the whole. In software, that means site reliability engineers, on-call rotas, platform teams and the managers who read their incident reports.
For an individual engineer, the framework changes what an incident review is for. If catastrophe requires multiple aligned faults, then the useful output of a review is not a single fix but an inventory of the conditions that made the alignment possible — and an honest account of how the system looked from inside at the time, before anyone knew how the story ended.
For managers, the implication is uncomfortable. If practitioners are the source of adaptability rather than the source of error, then reducing their discretion in the name of standardisation may remove the mechanism that has been quietly absorbing failures. Procedures still matter, but a system that permits no deviation from them has no capacity to handle situations the procedures did not anticipate.
For organisations subject to regulation or legal exposure, there is genuine friction. Regulators, insurers and courts generally require a determination of cause. A framework that says root cause is a social construction does not map cleanly onto that requirement, whatever its analytical merits.
Where informed people disagree
The disagreement is real and it is not settled. One line of criticism holds that rejecting root cause analysis, taken literally, removes a tool that works well in a large class of ordinary failures. Not every incident is a complex emergent event; some are a bad configuration change, and identifying that change is genuinely useful. Critics argue that the framework is sometimes invoked to avoid accountability rather than to improve analysis.
A second line of criticism concerns evidence. The document asserts rather than demonstrates. Its propositions are plausible and match many practitioners’ experience, but experience-matching is a weak test — a framework that explains every failure after the fact may not predict any of them in advance.
A third area of contention is scope. The original context involves systems where failure kills people. Whether the same reasoning transfers cleanly to systems where failure means a service outage is debatable. Supporters argue the structural dynamics are identical and only the stakes differ; sceptics argue that borrowing the vocabulary of patient safety for commercial software inflates the rhetoric without improving the practice.
Between these positions sits a pragmatic middle: use causal chain analysis where the chain is short and clear, and reach for the systemic framing where it is not.
The practical implications
Several concrete changes follow if you take the framework seriously.
Write incident reviews that reconstruct what people knew at each moment, not what they should have known. Record the signals available at the time and the reasoning they supported. This is harder than listing what went wrong, and it produces more useful material.
Treat near misses as data. If catastrophe requires alignment of multiple faults, then events where faults nearly aligned carry almost the same information as events where they did. Most organisations do not capture these because nothing visible happened.
Look for the defences that are already being consumed. Retry budgets, spare capacity, timeout headroom and staffing slack all get spent quietly. Monitoring them tells you how close to the edge normal operation has drifted.
Notice where standard practice has been informally adapted. When people routinely work around a procedure, that is a signal about the procedure, and the workaround itself may now be load-bearing.
Resist the single-fix reflex. Adding a check after every incident accumulates complexity, and complexity is the substrate the framework identifies as the underlying hazard.
What to watch next
Three things are worth tracking. First, whether the language of resilience engineering continues to spread into fields with lower stakes, and whether that spread produces changed practice or only changed vocabulary. Second, how automated systems — including systems that generate or deploy changes with reduced human review — interact with a framework that locates adaptability in human practitioners. If the adaptive element is progressively removed, the framework’s own logic suggests the consequences are worth examining. Third, whether regulatory and legal expectations around causal determination shift, or whether the analytical and legal accounts of failure continue to diverge.
Frequently asked questions
What is “How Complex Systems Fail” about?
It is a short document setting out a series of propositions about failure in complex, high-hazard systems. Its main arguments are that such systems always run in a partially degraded state, that catastrophe requires multiple faults to align rather than one cause to occur, and that human operators are the element that adapts to keep the system running rather than the primary source of error.
Why does it say root cause analysis is wrong?
Because in a complex system many contributing conditions are present simultaneously, and selecting one of them as “the” cause is a choice rather than a discovery. The framework treats root cause designation as serving organisational needs — closing an investigation, assigning responsibility, satisfying external requirements — more than explanatory ones. Critics counter that for simple, well-bounded failures, causal identification remains genuinely useful.
Does it apply to software or only to medicine?
It originated in high-hazard operational contexts and has been adopted widely in software reliability work. Supporters argue the structural dynamics — many interacting components, incomplete visibility, continuous change — are the same regardless of domain, and only the consequences differ. Sceptics argue that transferring the vocabulary of life-critical safety to commercial services overstates the stakes without necessarily improving how incidents are handled.
What is the difference between complicated and complex?
A complicated system has many parts but behaves predictably, and can be understood by examining its components separately. A complex system produces behaviour through interaction between parts, so decomposing it destroys the property under study. The distinction matters practically: complicated systems respond well to detailed specification and checklists, while complex systems can generate failures that no component-level analysis would have anticipated.
How do I apply this to incident reviews?
Reconstruct what people knew at each point rather than judging against what is known afterwards. Record multiple contributing conditions instead of selecting one. Capture near misses, since they carry similar information to actual failures. Track how much safety margin normal operation is consuming. Be cautious about adding a new control after every incident, since accumulated controls increase the complexity that the framework identifies as the underlying hazard.
Is the document’s argument empirically proven?
No. It is a set of assertions rather than an empirical study, and it presents no data. Many practitioners find it matches their experience closely, but that is a weak form of validation — a framework flexible enough to explain any failure retrospectively may have limited predictive power. It is best read as a lens for structuring analysis rather than as a demonstrated result.
Sources and further reading
- The original document itself, circulated as a short public text and widely mirrored online; the primary material for anyone assessing the argument directly.
- Technology news aggregators, where the recent discussion thread and accompanying practitioner commentary can be read.
- Academic literature on resilience engineering and safety science, which provides the broader field the document sits within.
- Published incident review practices from organisations that operate large distributed systems, useful for seeing how the framework is applied or ignored in practice.
Surfaced from the hackernews signal “resurfaced systems-failure paper”. AI-assisted draft, editorially reviewed.
