Engineering Philosophy: Rich Hickey, Simple Is Not Easy

Key Takeaways

• Simple is not easy. Simple means un-braided – one concern per thing – and is objective; easy means familiar and near-to-hand, and is subjective. We constantly choose easy and mislabel it simple.
• Complecting is the root of complexity. Complexity is not the number of parts but how tangled they are. Braiding state to time, identity to behavior, or policy to mechanism is what makes a system you can only pray over.
• Decomplect relentlessly. Pull braided concerns into independent pieces you compose deliberately. Simplicity is “a choice” that “requires constant vigilance” – it never arrives by reaching for the familiar tool.
• Prefer values over places, data over objects. Make immutability the default and let the past accumulate as immutable facts rather than overwriting state in place – the discipline behind both Clojure and Datomic.

The Principle

“The roots of this word are ‘sim’ and ‘plex’, and that means ‘one fold or braid’ […] right next to or opposed to ‘complex’, which means ‘braided together’ or ‘folded together’.” – Rich Hickey, Simple Made Easy¹

Almost every argument about software quality is actually two arguments wearing one word, and Rich Hickey’s contribution is to pull them apart. Simple and easy are not synonyms. They are not even on the same axis: one measures the thing, the other measures your distance from it. Simple comes from the Latin simplex – one fold, one braid, one twist. It describes the thing itself: how many concerns are interleaved in it. It is objective, and its opposite is complex – braided together, folded over on itself. Easy, by contrast, derives from a root that means “to lie near,” the same root as adjacent.² Easy describes your relationship to the thing: how near it is to hand, how familiar, how little effort it takes you to start. It is subjective, and its opposite is hard.¹²

Once you see the distinction you cannot unsee it. The tool you reach for because it is one npm install away is easy. Whether it is simple – whether it tangles persistence into your validation into your UI into your business rules – is a completely separate question, and the answer is usually no. We choose easy constantly and call it simple, and then we drown in the complexity we invited. Hickey’s word for the act of tangling is complect: “to interleave or entwine or braid.”³ Complecting is the original sin. It is what turns a system you could reason about into one you can only pray over, because once two concerns are braided together you can no longer touch one without understanding and risking the other.

The discipline, then, is to decomplect – to relentlessly pull braided concerns into independent pieces – and Hickey is blunt about the cost. “Simplicity is a choice,” he says. “It’s your fault if you don’t have a simple system.”⁴ It does not happen by reaching for the familiar tool; it happens through “constant vigilance” and deliberate care.⁴ That is the whole principle in four words: simple is not easy. Simplicity is the harder, chosen, un-braided path, and it is the only one that compounds. The same conviction sits underneath the argument that quality is the only variable – you do not back into a clean system by taking the convenient step each time; you choose it, against the gradient, every time.

Context

Rich Hickey is an independent programmer who spent roughly two decades writing C++, Java, and C# systems for a living before he built the thing he is known for.⁵ He knew how to make big systems in those languages, and his conclusion after twenty years was not that they were missing features. It was that they were complecting machines – they made it effortless to braid concerns together and offered almost no help pulling them apart.

So he built the alternative himself, alone. Beginning around 2005, Hickey spent roughly two and a half years developing Clojure – much of it self-funded, working without a salary on a Lisp for the Java Virtual Machine that would make immutability and simplicity the path of least resistance rather than an act of heroism.⁵ He released it publicly in 2007. There was no company behind it, no committee, no grant. It was one programmer who had seen the disease up close deciding to spend years of his own runway building the cure. He later created Datomic, an immutable database,⁵ and gave a series of conference talks – Simple Made Easy, The Value of Values, Hammock-Driven Development, Are We There Yet? – that are, collectively, the most influential body of design philosophy in modern functional programming.⁶

The Work

Simple Made Easy: Simple vs. Easy, and Complecting

Delivered at Strange Loop in September 2011, Simple Made Easy is the talk that reorganized how a generation of programmers talk about complexity.¹ Its entire force comes from refusing to let simple and easy mean the same thing. Simple is about the construct – is it one fold or many braided together? Easy is about you – is it near to hand, familiar, within your current ability? You can have things that are simple but unfamiliar (hard to learn, easy to live with) and things that are easy but complex (familiar, comfortable, and quietly ruinous). Most of what the industry sells as productivity is the second kind.¹

The verb at the center is complect: to braid, interleave, entwine.³ Complecting is what makes a system complex – not the number of parts, but how tangled they are. State complects value and time. Objects complect state and identity and behavior. Inheritance, ORMs, conditionals scattered through a method – each braids concerns that could have stood apart. And the cost of a braid is not paid once; it is paid on every future change, because you can no longer touch one strand without disturbing all of them.

The cure is to decomplect – to separate the strands into independent things you can compose later, on your own terms. Hickey’s claim, and it is a strong one, is that decomplecting is not a loss of power. “You can write as sophisticated a system with dramatically simpler tools,” he says – the same programs, only ones you can actually reason about, change, and trust.⁴ Simplicity is not the beginner’s subset of capability. It is the expert’s discipline of refusing to braid.

Clojure: A Lisp for the JVM, Data Over Objects

Clojure is the principle made executable: a dynamic, functional Lisp dialect that runs on the JVM, designed by Hickey as “a Lisp for Functional Programming symbiotic with an established Platform designed for Concurrency.”⁷ Two decisions encode the philosophy. First, immutability is the default, not an option – Clojure’s core data structures are immutable and persistent, so the most natural thing to write is also the thing that cannot be corrupted by a far-away mutation.⁷ Second, data over objects: rather than a sprawl of bespoke classes each with private state and behavior braided in, Clojure favors “many functions defined on few primary data structures” – sequences, maps, vectors, sets.⁷ Just use maps. Just use data.

This split is decomplecting at the level of a language’s grammar. Objects braid together state, identity, and behavior into a single sealed thing; Clojure pulls them apart – immutable values for what a thing is, plain functions for what you do to it, explicit reference types for managed change over time. By making the JVM the platform rather than fighting it, Hickey also decomplected language from runtime: Clojure gets the JVM’s maturity, libraries, and performance for free, and spends its novelty budget entirely on the model of state and time.⁷

The Value of Values: Immutability and Datomic

The Value of Values takes the immutability argument up a level, to the database itself. Hickey’s target is what he calls place-oriented programming (PLOP): “anytime new information replaces old information, you’re doing Place-Oriented Programming.”⁸ We update a record in place, the old value is gone, and with it the history. He argues this is a holdover from an era of scarce memory, and that it throws away exactly what a business needs to reason – the past. A value, by contrast, is immutable by definition: a fact is “something that happened, something known to have happened,” and a fact cannot be updated, only superseded by a newer fact.⁸ A new president does not overwrite the old one; it appends.

Datomic is that idea built as a database. It is fundamentally immutable: “A Datomic database is a set of immutable atomic facts called datoms,” and “Datomic transactions add datoms, never updating or removing them, so you have a complete audit trail.”⁹ Because nothing is ever overwritten, the database can be treated as a value as of a point in time – you can query it “as-of” any past instant with the same queries you run against the present, with no change.⁹ The database stops being a single mutable place and becomes a series of values over time. State, identity, and time – decomplected, in a production data store.

Hammock-Driven Development: Think First

The companion to all of this is a talk about when the real work happens, and Hickey’s answer is: before you touch the keyboard. In Hammock-Driven Development he argues that “the least expensive place to fix bugs is when you’re designing your software,” and that most serious software failures are failures of misconception – we did not understand the problem before we started solving it.¹⁰ The remedy is to state the problem explicitly, gather the facts and constraints, and then think – including by handing the problem to your “background mind,” which makes the connections your analytical “waking mind” cannot force.¹⁰ The hammock is the literal furniture for doing nothing but thinking, undisturbed.

Hammock-driven development is the practice that makes simplicity possible at all. You cannot decomplect a system you do not yet understand, and you cannot understand it while racing to compile. Hammock-driven development is the unglamorous front half of simple is not easy: the deliberate, slow, vigilant thinking that has to happen before the un-braided design can appear.

The Method

The method is one distinction – simple is not easy – applied with unusual stubbornness across a language, a database, and a working style.

Separate “simple” from “easy” before every decision. Ask of any tool or design: is this un-braided (simple), or merely familiar and near to hand (easy)? They are different axes, and conflating them is how complexity sneaks in disguised as productivity.¹²

Hunt for complecting and decomplect it. Complexity is not the count of parts; it is how tangled they are. Find where state is braided to time, identity to behavior, policy to mechanism – and pull the strands apart into independent pieces you compose deliberately.³

Prefer values and data to places and objects. Make immutability the default. Represent information as plain data – maps, vectors – and operate on it with functions, rather than sealing state and behavior together inside objects.⁷⁸

Treat the past as a value, not as overwritten state. New information should append, not destroy. A system that accumulates immutable facts over time can be reasoned about, audited, and queried as-of any moment – which a place that is overwritten in situ never can.⁸⁹

Think before you type. The cheapest place to fix a defect is in the design. State the problem, feed it to your background mind, and earn the simple design by understanding the problem first.¹⁰

Accept that simplicity is hard and chosen. It does not arrive by reaching for the easy thing. “Simplicity is a choice,” and it requires “constant vigilance.” The convenient path and the simple path are rarely the same path.⁴

Influence Chain

Who Shaped Him

Lisp and John McCarthy. Clojure is, by Hickey’s own framing, “a Lisp not constrained by backwards compatibility” – the code-as-data homoiconicity and the macro power come straight from McCarthy’s lineage, extended to maps and vectors rather than just lists.⁷ (Direct influence)

John Backus and the functional-programming tradition. Backus’s 1977 Turing Award lecture, Can Programming Be Liberated from the von Neumann Style?, is the canonical argument against assignment-driven, place-oriented computing. Hickey’s war on place-oriented programming and mutable state is that argument carried into production. (Formative influence)

The Java Virtual Machine. Rather than treat the runtime as an enemy to abstract away, Hickey made the JVM the platform and built the language on top of it – a deliberate decomplecting of “language” from “runtime” that gave Clojure maturity and reach from day one. (Direct influence)

Relational and value-oriented thinking. Datomic’s view of data as immutable facts accumulated over time, queryable as-of any point, descends from the relational tradition’s separation of facts from their storage – the idea that information has an existence independent of the place that currently holds it.⁸⁹ (Formative influence)

Who He Shaped

The functional-programming renaissance. Clojure, alongside Scala and others on the JVM, helped move functional programming from academic curiosity to mainstream production, and Hickey’s talks became the shared vocabulary – “simple,” “easy,” “complect” – that working programmers now use to argue about design.

Immutability, mainstreamed. The idea that immutable-by-default data is the sane default, not an exotic constraint, propagated far beyond Clojure. It is now table stakes in language and library design across the industry.

React, Redux, and the front-end world. The value-oriented model – immutable state, pure transformations over data, identity and state pulled apart – is the conceptual spine of React and especially Redux. A generation of front-end engineers absorbed Hickey’s value-thinking without always knowing whose it was.

The Throughline

John Carmack strips a renderer to the fast, simple core and refuses every feature that would braid slowness into the inner loop; Hickey strips a system to its un-braided concerns and refuses every abstraction that would complect them. Both treat simplicity as the hard, chosen thing rather than the default. And where Linus Torvalds prizes the “good taste” that makes a special case disappear into the general one, Hickey prizes the decomplecting that makes two tangled concerns stand apart as one – the same instinct seen from opposite ends: the right structure is not decoration on the problem, it is the problem correctly separated into its real parts. Yukihiro Matsumoto optimized Ruby for how it feels to write – the easy, in Hickey’s vocabulary – while Hickey optimized for what the thing is – the simple; together they map the two axes Hickey spent a whole talk insisting we stop confusing. (Series bridge)

What I Take From This

The lesson I keep is that easy is a trap dressed as a virtue. Almost every regret in a codebase started as a reasonable reach for the near-to-hand thing – the convenient library, the quick mutation, the one extra responsibility folded into a class that already existed. None of it felt like a mistake, because easy never does. Hickey’s gift is the vocabulary to catch it in the moment: to stop and ask is this simple, or just easy? and to know that the honest answer is usually the inconvenient one. That is the same standard as quality being the only variable – the question is never “what can I reach fastest?” but “what is actually un-braided here?”

In the world I build in now – agents, tool loops, harness code where state, prompts, retries, and side effects love to braid themselves into one ungovernable thing – the temptation is maximal easy: stack frameworks, smear state across the loop, complect the decision logic with the I/O with the logging until no one can change a part without risking the whole. The Hickey move is to decomplect: pull the policy out of the mechanism, make the state immutable where it can be, treat each run as a value rather than a place I overwrite. That conviction – that taste is a technical system you choose with vigilance, not a vibe you inherit by reaching for what is near – is the throughline from a self-funded Lisp in 2007 to a 2026 agent harness. Simple is not easy. Choose it anyway.

FAQ

What is the difference between simple and easy?

In Rich Hickey’s framing from Simple Made Easy, simple and easy are different axes entirely. Simple comes from the Latin simplex – “one fold or braid” – and describes the thing itself: how few concerns are interleaved in it. It is objective, and its opposite is complex (“braided together”).¹ Easy derives from a root meaning “to lie near,” the same root as adjacent; it describes your relationship to the thing – how familiar and near-to-hand it is.² It is subjective, and its opposite is hard. Something can be simple but unfamiliar, or easy but deeply complex. Hickey’s point is that we constantly choose easy and mislabel it simple, and pay for the complexity later.¹

What does “complect” mean?

Complect is the verb Hickey revived in Simple Made Easy for the act of braiding concerns together. He defines it directly: “It means to interleave or entwine or braid.”³ Complecting is what makes a system complex – not the number of parts, but how tangled they are. When two concerns are complected (say, state and time, or identity and behavior), you can no longer change one without understanding and risking the other. The remedy is to decomplect: pull the strands into independent pieces you can compose deliberately. Hickey treats decomplecting as the core discipline of building simple systems.³

What did Rich Hickey build?

Rich Hickey is an independent programmer who created Clojure, a dynamic, functional Lisp dialect that runs on the Java Virtual Machine. He developed it largely alone over roughly two and a half years, much of that self-funded without a salary, and released it in 2007.⁵⁷ He later created Datomic, an immutable database that never overwrites data but accumulates immutable facts (“datoms”) over time, so the database can be queried as a value as-of any past point.⁹ He is also widely known for a series of conference talks – Simple Made Easy, The Value of Values, Hammock-Driven Development, and Are We There Yet? – that shaped how the industry talks about complexity, immutability, and design.⁵⁶

Did Rich Hickey say “programmers know the benefits of everything and the tradeoffs of nothing”?

This one-liner is very widely attributed to Hickey and captures his thinking exactly, but it does not appear verbatim in his primary talk transcripts; it is a crystallized paraphrase that has circulated through books and conference talks.¹¹ The closest verbatim primary version is in Design, Composition, and Performance, where he urges taking a solution apart “to see not just the benefits, right? Those are pretty evident usually. But also the tradeoffs: what part of this is not going to work?”¹² The sentiment is unambiguously his – that engineers over-index on what a tool gives them and under-examine what it costs – but the punchy aphorism is best treated as a paraphrase rather than a direct quotation.

Sources