Rich Hickey's talk "Simple Made Easy" argues that "simple" and "easy" are different properties. What is the distinction, and how would you argue objectively that one design is simpler than another rather than just more familiar?
answer
- sim-plex = one braid; complex = braided together
- Easy = "lying near" — relative to you
- Simple is objective; easy is subjective
- Simple ≠ few: four one-job things beat one four-job thing
- Argue with change amplification and state-space counts
basics
~20 sSimple means one concern, not braided together with others — an objective property of the design. Easy means familiar or close at hand — relative to you. To argue simplicity, count interleaved concerns, dependencies, states and hidden couplings, not how quickly you can start.
solid answer
~50 sHickey traces the words: *simple* comes from sim-plex, one fold or braid — the opposite of *complex*, many braided together. So simplicity is about how many concerns a construct interleaves, and it is an objective property you can inspect. *Easy* comes from a root meaning "lying near" — near your existing skills, near at hand via a tool or framework, near to install. Easy is relative to the observer and says nothing about the artifact. His warning: teams optimise for easy (familiar tools, quick starts, one-line magic) and get complexity they must live with forever, because complexity limits how much of the system you can reason about at once. To argue objectively, avoid "it feels cleaner" and cite measurable things: number of concerns a unit touches, number of dependencies and cycles, mutable shared state, implicit control flow, number of configuration knobs, the size of the reachable state space, and how many places a typical change must touch.
go deeper
State the definitions: simple means not braided with other concerns and is a property of the thing; easy means familiar or close at hand and is relative to you. Give one example of each.
Show you can spot easy-but-complex choices (implicit framework magic, shared mutable caches) and that fewer things is not the same as simpler things.
Argue objectively with measurable properties — concerns per module, dependency cycles, reachable state combinations, change amplification — and connect the idea back to KISS being misapplied as 'choose the familiar'.
Tie it to portfolio decisions: how a preference for easy accumulates into platform-wide braiding, how to encode simplicity constraints as automated checks, and how to weigh genuine familiarity/hiring risk against long-term complexity cost when choosing technology.
## The distinction Rich Hickey (*Simple Made Easy*, Strange Loop 2011) argues we conflate two unrelated properties: - **Simple** — from Latin *sim-plex*, "one fold/braid". A thing is simple when it does not interleave separate concerns. Opposite: **complex** (*com-plex*, braided together). Simple is an **objective**, inspectable property of the artifact: you can ask "how many concerns are twisted together here?" - **Easy** — from a root meaning "lying near" (cf. *adjacent*). A thing is easy when it is near at hand: near your current knowledge, one command away, already in your toolchain. Easy is **relative to a person or situation** and says nothing about the artifact. Hickey's classic examples of things that are easy but complect (braid) concerns: mutable state braids value and time; inheritance braids type with implementation; ORMs braid the object model with persistence; conditionals scattered through a routine braid policy with mechanism; a framework's "magic" braids your logic with its lifecycle. Contrasting simpler constructs: values, pure functions, data as data, queues, declarative rules, composition over inheritance. He also separates **simple/complex** from **few/many**: one thing that does four jobs is complex; four separate things each doing one job are many but simple. And he distinguishes the **construct** (what you type) from the **artifact** (what runs and must be maintained) — arguing that we should judge the artifact, because that is what we live with. ## Why this matters for KISS and YAGNI KISS is usually stated as "keep it simple" but is applied as "keep it easy" — pick what is familiar and fastest to start. Hickey's point is that these diverge: the easy choice (an all-in-one framework, a clever DSL, a shared mutable cache) frequently increases braiding, and braiding is what caps how much you can reason about later. YAGNI, meanwhile, guards against additional braiding you don't even need yet. The practical rule: when someone says a design is simpler, ask *which sense*. "I can start faster" is easy. "Fewer things are entangled" is simple. Both matter — you should not pick constantly unfamiliar tools — but only one of them predicts long-term change cost. ## Making the argument objectively Replace taste with observable properties: 1. **Concerns per unit** — list what a module knows about: domain rule, persistence, transport, retry policy, feature flag, auth. Every extra one is a braid. 2. **Fan-out / dependency count and cycles** — how many other things must exist for this to work; cycles in particular make local reasoning impossible. 3. **Shared mutable state** — how many independent paths can mutate the same thing; how much of behaviour depends on time and order. 4. **Implicit control flow** — reflection, dynamic proxies, lifecycle callbacks, ambient context: does reading the code tell you what runs? 5. **State space** — number of boolean flags, nullable fields and enum combinations reachable; `2^n` combinations is a hard, countable measure of complexity. 6. **Change amplification** — for a set of realistic requirements, count how many files/modules/teams each one touches. This is the most persuasive metric because it maps to cost directly. 7. **Configuration surface** — knobs whose combinations you must support and test. 8. **Cognitive load per unit** — supporting metrics like cyclomatic complexity or nesting depth are weak individually but useful as trend indicators. A good interview move: present two candidate designs and compare them on three of these axes with numbers, rather than adjectives. ## Related ideas worth naming - **Ousterhout (*A Philosophy of Software Design*)**: complexity manifests as *change amplification*, *cognitive load*, and *unknown unknowns*; deep modules (simple interface, substantial implementation) beat shallow ones — an interface-cost view of KISS. - **Gall's law**: complex systems that work invariably evolved from simple systems that worked. - **"Worse is better"** (Richard Gabriel): a simpler implementation with a slightly less complete interface often wins in practice through spread and adaptability. - **Accidental vs essential complexity** (Brooks): braiding is a prime source of accidental complexity. - Caution: familiar tools genuinely lower risk. The mature position is not "always choose the unfamiliar simple thing" but "know which property you are buying, and don't let *easy* silently sell you *complex*."
- Give an example of a technology that is easy but not simple, and one that is simple but not easy.An ORM with lazy loading is easy — one annotation and persistence disappears — but braids the object graph with query behaviour and transaction boundaries, so performance and correctness bugs surface far from their cause. Immutable data with explicit state transitions is simple — value and time are separated — but is initially unfamiliar to teams used to mutating objects in place.
- Someone says "this design is simpler" but means they can start faster. How do you reframe the discussion?Name the two properties and ask which one is being claimed. Then compare the candidates on countable axes: concerns per module, dependency cycles, reachable state combinations, and how many places a realistic set of upcoming changes would touch. That converts a taste argument into an evidence one.
A four-in-one shampoo bottle is easy — one thing to grab. Four separate bottles are more things but simpler: you can change the conditioner without affecting the sunscreen. Braiding four jobs into one container is convenient right up to the moment you need one of them to be different.