John Gall’s Systemantics explained why large, clever systems fail — and why simple, resilient ones survive. This page distills his rules and applies them directly to software engineering.
How systems actually behave — not how designers wish they would.
Gall’s central insight: systems are not extensions of your intentions. Once created, they acquire their own momentum, incentives, and failure modes.
A complex system designed from scratch never works. A working complex system evolves from a simple system that worked. Big-bang designs fail; small systems that grow survive.
A system is never what you think it is. Once running, it starts serving itself: preserving its own processes, metrics, and bureaucracy — often at odds with your original goal.
Push a system and it pushes back — usually in ways you didn’t predict. Unexpected behavior is not an exception; it is the default.
Large systems resist change and often oppose their own stated functions. Scale amplifies inertia, delays, and disconnect from reality.
In a system, everything is connected. A “local” tweak can trigger global side effects, surprising outages, or bizarre feedback loops.
Systems that operate at maximum efficiency eliminate redundancy and slack — the very things that absorb shocks. Hyper-efficient systems are dangerously brittle.
Systems tend to fail at peak stress, not during routine operation. And they fail in new and interesting ways, not just along known failure paths.
The information you have is rarely the information you need. Reporting, dashboards, and status flows are all filtered by incentives, tools, and politics.
Left alone, systems accumulate rules, steps, and roles. They rarely shrink. Once started, they are hard to stop or dismantle cleanly.
From systems theory → concrete engineering practices.
Treat your codebase, infrastructure, and organization as one interconnected system. The practices below translate Gall’s laws into everyday engineering decisions.
Complex systems must evolve from a tiny working core.
Efficiency kills resilience if you remove all buffers.
Tight dependencies turn small bugs into large incidents.
Systems fail under stress — in ways you didn’t imagine.
Your model of the system is always missing something.
Large rewrites create new complex systems that don’t work yet.
Systems grow and encroach — including your processes.
Reality wins against architecture diagrams every time.