Gall’s Law
Complex systems that work evolve from simple systems that worked. Start small, get it working, then scale.
author
John Gall. Also known as “Systemantics principle”
Model type
About
From John Gall’s Systemantics (later The Systems Bible). The law cautions against big-bang designs: you reach reliable complexity by iterating from a working, simple core.
How it works
Working core first – a minimal, end-to-end “walking skeleton” proves the architecture and feedback loops.
Iterate outward – add capabilities in small, reversible steps; integrate continuously.
Stabilise interfaces – keep contracts simple; hide internal complexity behind clear boundaries.
Bias to decoupling – prefer modules/services that can evolve independently.
Evidence over theory – operating telemetry guides what to build next.
Iterate outward – add capabilities in small, reversible steps; integrate continuously.
Stabilise interfaces – keep contracts simple; hide internal complexity behind clear boundaries.
Bias to decoupling – prefer modules/services that can evolve independently.
Evidence over theory – operating telemetry guides what to build next.
Use cases
Product development – ship an MVP that actually works; extend based on usage.
Software/ data architecture – start with a thin vertical slice; scale with modules and queues.
Operating model design – pilot a small, self-contained team/process before roll-out.
M&A integration/ carve-outs – stand up the minimum standalone capability, then harden and expand.
Policy/ process change – trial limited-scope rules; codify after results.
Software/ data architecture – start with a thin vertical slice; scale with modules and queues.
Operating model design – pilot a small, self-contained team/process before roll-out.
M&A integration/ carve-outs – stand up the minimum standalone capability, then harden and expand.
Policy/ process change – trial limited-scope rules; codify after results.
How to apply
Define the smallest end-to-end job the system must accomplish.
Build a walking skeleton (deployable, observable, secure enough for the slice).
Instrument latency, error rates, cost, and user outcomes; set guardrails.
Iterate in small increments; keep interfaces stable as internals change.
Refactor and retire complexity regularly; don’t let temporary scaffolds harden.
Build a walking skeleton (deployable, observable, secure enough for the slice).
Instrument latency, error rates, cost, and user outcomes; set guardrails.
Iterate in small increments; keep interfaces stable as internals change.
Refactor and retire complexity regularly; don’t let temporary scaffolds harden.
pitfalls and cautions
Fake MVPs – demos that don’t run in production violate the law’s premise.
Deferred non-functionals – security, reliability, and compliance need a minimal viable level from day one.
Complexity displacement – pushing complexity onto users or ops just moves the problem.
Interface churn – changing contracts breaks evolution; version and deprecate.
Deferred non-functionals – security, reliability, and compliance need a minimal viable level from day one.
Complexity displacement – pushing complexity onto users or ops just moves the problem.
Interface churn – changing contracts breaks evolution; version and deprecate.