Gall’s Law
John Gall. Also known as “Systemantics principle”
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.
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.
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.
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.
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.