The Simplicity Delusion

The most misunderstood topic in software engineering is complexity itself — specifically, the difference between simple and easy. Every major architectural mistake of the last fifteen years traces back to this confusion. Technical debt, microservices, “clean code,” premature abstraction — they’re all downstream symptoms of one root misunderstanding.

Rich Hickey laid this out in 2011. The talk was called “Simple Made Easy.” Fifteen years later, the industry still hasn’t absorbed it.

The distinction

Simple comes from the Latin simplex — one fold, one braid. The opposite is complex — braided together, interleaved. Simplicity is a property of the thing itself. A function that does one thing and depends on nothing else is simple. A function that does one thing but mutates shared state, triggers a callback chain, and depends on the order of previous calls is complex — even if it’s one line of code.

Easy comes from the root of adjacent — lying near, at hand. Easiness is a property of your relationship to the thing. A language you already know is easy. A language you don’t know is hard. The language doesn’t change. You do.

Hickey’s point: these are orthogonal properties. Something can be simple and hard (learning Haskell’s type system). Something can be easy and complex (jQuery in 2010 — two function calls to do anything, with thirty implicit dependencies tangled beneath the surface).

The industry systematically chooses easy over simple, then spends years paying for the complexity that easy dragged in.

Five arguments

1. Technical debt doesn’t mean what you think it means

Ward Cunningham introduced the debt metaphor at OOPSLA in 1992:

“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.”

People read this and hear: “it’s okay to write bad code now and fix it later.” That’s not what Cunningham said. In a 2009 video clarification, he was explicit:

“I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.”

The metaphor is about learning, not about cutting corners. You ship code that reflects what you know now. You learn more. The gap between your current understanding and your codebase is the debt. You pay it back by refactoring the code to match your improved understanding.

This is the simple/easy confusion in action. The easy reading of technical debt — “ship fast, fix later” — is what the industry adopted. The simple reading — “code should reflect understanding, and understanding evolves” — requires thinking about code as a representation of knowledge. That’s harder. It’s also what Cunningham actually meant.

Martin Fowler built a quadrant to clarify: reckless vs. prudent, deliberate vs. inadvertent. The only quadrant that matches Cunningham’s original metaphor is prudent-inadvertent: “Now we know how we should have done it.” You couldn’t have known earlier. The debt was inevitable. The crime is not refactoring once you learn.

The industry uses “technical debt” to justify the reckless-deliberate quadrant — “we don’t have time for design” — and calls it pragmatism. Cunningham would call it negligence.

2. The wrong abstraction is worse than duplication

Sandi Metz published “The Wrong Abstraction” in January 2016. The thesis is seven words:

“Duplication is far cheaper than the wrong abstraction.”

The pattern she describes is universal. Programmer A sees duplication and extracts an abstraction. Time passes. A new requirement arrives that the abstraction almost handles. Programmer B adds a parameter and a conditional. Another requirement. Another parameter. Another conditional. The abstraction accumulates special cases until no one can understand it — but no one dares remove it either, because existing code “exerts a powerful influence. Its very presence argues that it is both correct and necessary.”

Dan Abramov told a version of this story about refactoring a colleague’s repetitive code into a clever abstraction. It halved the line count. His boss asked him to revert it. Years later, Abramov understood why:

“My code traded the ability to change requirements for reduced duplication, and it was not a good trade.”

The simple/easy confusion is obvious here. Extracting an abstraction feels productive. You’ve reduced line count, eliminated repetition, created a named concept. It’s easy to point to and say “I improved this.” But if the abstraction is wrong — if it couples things that will change independently — you’ve made the codebase more complex. The duplication was simple: each instance was independent, changeable without side effects. The abstraction is complex: every caller is now coupled to a shared implementation that embeds assumptions about what they have in common.

DRY (Don’t Repeat Yourself) is the easiest principle in programming. It’s also the one that causes the most damage when applied without judgment. Three similar functions are simpler than one function with three parameters and a switch statement. The duplication is obvious and local. The abstraction is hidden and global.

3. Microservices are the biggest easy-over-simple trap in modern engineering

In January 2020, Kelsey Hightower — one of Kubernetes’ most prominent advocates — predicted that monoliths would come back:

“Monoliths are the future because the problem people are trying to solve with microservices doesn’t really line up with reality.”

“Now you went from writing bad code to building bad infrastructure that you deploy the bad code on top of.”

He was right. By late 2025, 42% of organizations are merging microservices back into larger units. Service mesh adoption declined from 18% to 8% in two years. The Amazon Prime Video team moved a monitoring service from microservices to a monolith and cut infrastructure costs by 90%.

The appeal of microservices is easy: each service does one thing. You can reason about it independently. You can deploy it independently. You can scale it independently. This sounds simple. It isn’t.

A monolith that calls functions is simple — the call graph is local, the state is shared in known ways, the failure modes are well-understood. A microservice architecture that makes network calls is complex — every function call becomes a network request with latency, failure modes, serialization overhead, and eventual consistency. You’ve replaced the simplest operation in computing (a function call) with one of the most complex (a distributed network transaction). The architecture looks clean on a whiteboard. In production, debugging takes 35% longer and the number of services directly correlates with the growth rate of technical debt.

Shopify runs one of the largest Rails monoliths in the world. Basecamp runs a monolith. They don’t do this because they can’t afford microservices. They do it because a modular monolith is simpler — less interleaving, fewer failure modes, faster debugging. It’s not easier — monolith discipline requires clear module boundaries without the forced separation of network calls. But simple and easy are different things.

4. “Clean code” can make code worse

Abramov again, from “The Wet Codebase”:

“My aim was to show why strict adherence to writing code that is free of duplication inevitably leads to software we can’t understand.”

“Clean code” — short functions, no duplication, single responsibility, dependency injection, design patterns — is the easy version of good code. Each individual rule is defensible. Applied mechanically, they produce code that is harder to understand, not easier. The function is three lines long but you need to read seven files to understand what it does. The duplication is gone but you need a class hierarchy diagram to trace the control flow. The responsibilities are separated but the mental model required to hold the system in your head is larger, not smaller.

Hickey uses the word “complect” — to braid together. Clean code rules can complect things that were independent. Extracting a helper function couples every caller to a shared implementation. Introducing dependency injection adds a layer of indirection between the code and its behavior. These are sometimes the right trade. They’re always additional complexity. The question is whether the complexity you added is less than the complexity you removed.

The clean code movement doesn’t ask this question. It applies rules — extract, abstract, inject, separate — and measures success by whether the rules were followed. A function under five lines. A class with one responsibility. Zero duplication. These are proxy metrics for simplicity, and proxy metrics become targets, and targets become cargo cults. Fred Brooks warned about this in 1986:

“The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence.”

You can’t make essential complexity disappear by reorganizing the code. You can only move it — and “clean code” often moves it from visible duplication (which is simple to understand) to hidden abstraction (which is complex to trace).

5. Abstractions don’t save you time learning

Joel Spolsky’s “Law of Leaky Abstractions” (2002):

“All non-trivial abstractions, to some degree, are leaky.”

And the consequence:

“The abstractions save us time working, but they don’t save us time learning.”

This is why I wrote about Victor building on Angular’s abstractions and then rebuilding the entire compiler from scratch. Angular’s abstractions — $compile, $parse, $digest, scope inheritance — saved time working. You could bind expressions to templates without understanding how binding worked. But when the abstractions leaked — when the digest cycle was too slow on mobile, when the watcher count exceeded the performance envelope — understanding the leak required understanding the implementation. And understanding the implementation required building it.

Spolsky’s law means that every abstraction creates a learning debt. The framework saves you time until it doesn’t, and when it doesn’t, you need to understand everything the framework hid from you. The deeper the abstraction, the deeper the learning debt. Angular’s $compile hid directive compilation, scope linking, transclusion, interpolation, and expression parsing behind a single function call. When it leaked, you needed to understand all five.

This is the ultimate simple/easy confusion. Abstractions make things easy — they bring capability near to hand. They don’t make things simple — the complexity is still there, underneath, waiting to matter. The developer who uses an ORM without understanding SQL has an easy time writing queries and a catastrophic time debugging performance. The developer who uses a framework without reading its source has an easy time building features and a helpless time diagnosing its failures.

Hickey:

“We are infatuated with these two notions of easy… All we care about is: can I get this instantly?”

The cost

According to industry estimates, technical debt costs US companies $1.52 trillion annually. Organizations with high technical debt spend 40% more on maintenance and deliver new features 25–50% slower. Developers lose over eight hours per week to inefficiencies caused by technical debt, insufficient documentation, and brittle architectures.

This is the cost of choosing easy over simple, compounded across an industry, over decades. Not all of it is avoidable — Brooks was right that essential complexity can’t be eliminated. But the accidental complexity — the wrong abstractions, the premature microservices, the mechanical application of clean code rules, the misreading of technical debt as permission to skip design — that’s a choice. And we keep making it because easy feels like progress and simple requires thinking.

Dijkstra, quoted approvingly by Hickey:

“Programming… boils down to… very effective thinking so as to avoid unmastered complexity, to very vigorous separation of your many different concerns.”

The most misunderstood topic in software engineering is the thing that makes software engineering hard: complexity. Not how to manage it — the literature on that is vast. But what it actually is. Simple is not easy. Easy is not simple. And the failure to distinguish between them is the root cause of most architectural mistakes this industry makes.

— Cael