Discover more from Res Extensa
Gall's Law: But First, Simplify
Res Extensa #43 :: The simplicity to complexity spectrum, dead vs. living systems, Gall's Law in the wild
John Gall's book Systemantics is a weird one. It's not a book so much as a collection of casual observations and witty one-liner critiques on how and why systems fail. It almost reads like a stream-of-consciousness rant on every annoying thing Gall encountered in his career up to that point. But the bulk of his observations are rooted in experience, in first-hand observation of systems design gone awry. It's readable, brief, and gets to the point without belaboring each subject.
The bit he's perhaps best known for is Gall's law, which offers a deep insight about systems design, one that applies to all fields of study:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
We've all seen it time and again. Anyone can conjure examples from memory where a solution to a problem ended up adding more complexity instead of helping. Then we did another thing that added more. A complexity doom loop.
To comprehend the Law's significance, you first have to appreciate the nature of complexity in systems. A system is a set of interrelated, interacting elements that form a unified whole. Could be a software program, a business process, a biological ecosystem, or any number of other structured assemblies. A complex system implies multiple elements with various interactions that can be difficult to understand, predict, or manage. Complexity often comes with greater flexibility, capability, and power, but it also introduces increased fragility, risk of failure, unexpected interactions, and difficulties in diagnosing and fixing problems.
Systems are intricate, interconnected composites of inflows and outflows. One things flows into the next, creates feedback loops (positive or negative). It doesn't take too complex a system to make it exceedingly hard to predict how turning a knob will cascade through the system. (We went deeper on systems theory back in RE #6)
If your simple system isn't currently working, there must be missing understanding of the problem, or of the simple system's working elements.
Thinking in Systems reminds us that systems assemble bottom-up:
Hierarchies evolve from the lowest level up—from the pieces to the whole, from cell to organ to organism, from individual to team, from actual production to management of production.
The simple-before-complex framing is straightforward. Every reasonable person agrees with this — you know, "don't put the cart before the horse" and all that.
But the less-appreciated aspect of the law is violated all the time: that the simple system must work before complexifying.
You have to define and understand what "working" looks like to determine if your simple system, process, or product is ready for the next addition. This can be a subject of much debate, of course. But luckily, the simpler our system is, the clearer it should be to test for "fitness", to see whether and how well it's working.
First you must simplify
Gall's advice calls to mind a couple of similar ideas popularized by Nassim Taleb.
"Via negativa" is an idea rooted in theology meaning, literally, "by way of removal". When confronted with a complex problem you're trying to understand, with too many factors to get your head around, start by removing, not adding more complexity.
Another one is "iatrogenics", taken from the world of medicine. You've likely heard of this: the treatment is worse than the disease. Or the treatment causes more problems than it solves. In computer science, a programmer once said:
Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.
Before we start adding new complexity to a problem, make sure we have a simple, working version that we understand.
Way back in RE #4 we looked at the concept of "legibility", a force that compels people to design complex systems with a totalizing, top-down vision. In Seeing Like a State, James Scott calls it "authoritarian high modernism": designers conjuring greenfield plans (of buildings, cities, farms, forests, etc.) and attempting to impose them from above. The high modernist worldview assumes it can corral the tangled web of interactions that happen in the real world — that the designer "knows best". A total violation of Gall's Law.
The outcome of these visionary projects, as described in detail by Scott, is nearly always a complex but dead system. A city void of life, with empty streets, unused buildings, unhealthy forests, poorer people. The high modernist visionary falls victim to their overconfidence, and skips over building the simple systems that work first.
What we want in designing systems is to create living, healthy ones. Complexity for a purpose, rather than complexity for its own sake.contrasts dead vs. living complexity this way:
Dead complexity: imposed, top-down.
Living complexity: emergent, bottom-up.
Dead complexity: rational, designed.
Living complexity: messy, permissionless.
Dead complexity: fixed hierarchy, static categories
Living complexity: dynamic hierarchy, fluid and evolving statistical relationships across populations of individuals.
Examples from the wild
Lets look at some categories and how the simplicity → complexity progression applies.
Evolution is the pinnacle example of Gall's Law made real. All organisms accumulate adaptations that work. If an adaptation gives no advantage, it doesn't stick. If it generates fitness, it stays, becomes more advanced. Think limbs evolving feathers for insulation. Then large, wide limbs help with jumping, then controlled falls. Eventually onto gliding, then flight. Each step it's own working system.
Gall's guidance is embedded in agile, rightly understood. Or at least it’s supposed to be. Modern capital-A "Agile" has crossed up the incentives in a lot of ways, and been twisted into a dogma that veers a long way from the original premise. It's tempting to get fancy early in a design — to componentize and modularize right away. But it's merely a fun technical challenge more than a necessity to solve a problem. First keep it simple, then modularize later.
Internet standards have (mostly) come about through incremental proposal, implementation, and adoption. Even though now we've got W3C and IETF to manage hundreds of language and protocol standards, things like HTTP, TCP, SSL, and others began their lives as simpler RFC proposals, which were then appended to as new needs were discovered. Most protocols need to start simple to gain adoption. Without users and supporters, a protocol never takes off. To gain adopters, you need to keep it simple.
World wide web, wikis, RSS, JSON, you name it. They should begin with the simplest thing that could possibly work. One of my favorite quotes on standards comes from Where Wizards Stay Up Late, a history of the internet:
“Standards should be discovered, not decreed,” said one computer scientist in the TCP/IP faction. Seldom has it worked any other way.
As companies expand, their organizational structure evolves from a small, simple setup to a more complex one. Initially, a startup might have a flat hierarchy with a few employees handling multiple roles. As the business scales, departments, hierarchical levels, and specialized roles emerge to manage the growing complexity.
Planned, designed communities end up dead.
The Pruitt—Igoe housing project in St. Louis was built in the 50s in the "urban renewal" movement, but fell into disrepair and disuse. Brasília is famously overdesigned and empty, with vast urban areas, wide roads, and large spaces for expected high-density traffic and population influx, but much of it remains underpopulated and isolated.
The Burmese planned city of Naypyidaw was built as the new capital with big dreams (moved there in 2005 from Yangon), but is still most well known for its epic, eerily empty 10-lane highways.
The vibrant living cities we know of had no designer. Think Florence, Central London, Chinatown, downtown Boston, the French Quarter, Greenwich Village.
Modern supply chains are dense, intricate, and often fragile to shocks (see what happened during COVID). But they didn't start this way; all supply chains evolve into these elaborate webs through gradual change. They all originated as a barter between two tribes.
The US Constitution is a governing document for an union of (at the time) 13 states, in fewer than 8,000 words. The document federated a combined collection of existing, functional state governments. A simple description of basic principles that defines counterposing powers, and respects the hierarchical structure of decentralized state powers. In the time since, we added 37 more states to the federation. Modularity in governance.
Like most great mental models, Gall’s Law follows its own logic and keeps it simple. It’s a basic principle that helps filter your approach and ask yourself the question when faced with a complex problem: Is my approach simple enough? Does what we’ve already pieced together work before we add more parts, people, or processes?
Getting advanced is great if you first go through a “test and iterate” cycle to evolve a system. Just make sure you simplify first.
Res Extensa is supported by readers like you. If you enjoyed this post, and want to receive new posts and support my work, please subscribe.