nexus/sreweekly/markdown/492/04-easy-will-always-trump-simple.md

# Easy will always trump simple

- **期号**: SRE Weekly Issue #492（2025-08-31）
- **作者**: Lorin Hochstein
- **链接**: https://surfingcomplexity.blog/2025/08/17/easy-will-always-trump-simple/

## 简介

This article explores the difference between simple and easy, their relation to complexity, and the effect of production pressure.

## 正文

One of the early criticisms of Darwin’s theory of evolution by natural selection was about how it could account for the development of complex biological structures. It’s often not obvious to us how the earlier forms of some biological organ would have increase fitness. “What use”, asked the 19th century English biologist St. George Jackson Mivart, “is [half a wing](https://www.biointeractive.org/classroom-resources/origin-flight-what-use-half-wing)?” 

One possible answer is that while half a wing might not be useful for flying, it may have had a different function, and evolution eventually repurposed that half-wing for flight. This concept, that evolution can take some existing trait in an organism that serves a function and repurpose it to serve a different function, is called *exaptation*.

Biology seems to be quite good at using the resources that it has at hand in order to solve problems. Not too long ago, I wrote a [review of the book How Life Works: A User’s Guide to the New Biology](https://surfingcomplexity.blog/2024/07/07/book-review-how-life-works/) by the British science writer Philip Ball. One of the main themes of the book is how biologists’ view of genes has shifted over time from the idea  *DNA-as-blueprint* to *DNA*-as-*toolbox*. Biological organisms are able to deal effectively with a wide range of challenges by having access to a broad set of tools, which they can deploy as needed based on their circumstances. 

We’ll come back to the biology, but for a moment, let’s talk about software design. Back in 2011, Rich Hickey gave a talk at the (sadly defunct) Strange Loop conference with the title *Simple Made Easy* ([transcript](https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md), [video](https://www.youtube.com/watch?v=SxdOUGdseq4)). In this talk, Hickey drew a distinction between the concepts of *simple* and *easy*. *Simple* is the opposite of complex, where *easy* is something that’s familiar to us: the term he used to describe the concept of *easy* that I really liked was ***at hand***. Hickey argues that when we do things that are *easy*, we can initially move quickly, because we are doing things that we know how to do. However, because *easy* doesn’t necessarily imply *simple*, we can end up with unnecessarily complex solutions, which will slow us down in the long run. Hickey instead advocates for building *simple* systems. According to Hickey, simple and easy aren’t inherently in conflict, but are instead orthogonal. *Simple* is an absolute concept, and *easy* is relative to what the software designer already knows. 

I enjoy all of Rich Hickey’s talks, and this one is no exception. He’s a fantastic speaker, and I encourage you to listen to it (there are some fun digs at agile and TDD in this one). And I agree with the theme of his talk. But I also think that, no matter how many people listen to this talk and agree with it, *easy* will always win out over *simple*. One reason is the ever-present monster that we call ***production pressure***: we’re always under pressure to deliver our work within a certain timeframe, and easier solutions are, by definition, going to be ones that are faster to implement. That means the incentives on software developers tilts the scales heavily towards the *easy* side. Even more generally, though, *easy* is just too effective a strategy for solving problems. The late MIT mathematics professor Gian-Carlo Rota noted that [every mathematician has only a few tricks](https://web.archive.org/web/20180725194822/https://alumni.media.mit.edu/~cahn/life/gian-carlo-rota-10-lessons.html), and that includes famous mathematicians like Paul Erdős and David Hilbert. 

Let’s look at two specific examples of the application of *easy* from the software world, specifically, database systems. The first example is about knowledge that is at-hand. Richard Hipp implemented the SQLite v1 as [a compiler that would translate SQL into byte code](https://corecursive.com/066-sqlite-with-richard-hipp/), because he had previous experience building compilers but not building database engines. The second example is about an *exaptation*,  leveraging an implementation that was at-hand.  Postgres’s support for multi-version concurrency control (MVCC) relies upon an implementation that was originally designed [for other features, such as time-travel queries](https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html). (Multi-version support was there [from the beginning](https://apps.dtic.mil/sti/pdfs/ADA187244.pdf), but MVCC was only added in [version 6.5](https://www.postgresql.org/docs/6.5/release14025.htm)). 

Now, the fact that we rely frequently on *easy* solutions doesn’t necessarily mean that they are good solutions. After all, the Postgres source I originally linked to has the title [The Part of PostgreSQL We Hate the Most](https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html). Hickey is right that *easy* solutions may be fast now, but they will ultimately slow us down, as the complexity accretes in our system over time. Heck, one of the first journal papers that I published was a [survey paper on this very topic of software getting more difficult to maintain over time](https://www.sciencedirect.com/science/article/abs/pii/S0950584904001740?via%3Dihub). Any software developer that has worked at a company other than a startup has felt the pain of working with a codebase that is weighed down by what Hickey refers to in his talk as incidental complexity. It’s one of the reasons why startups can move faster than more mature organizations.

But, while companies are slowed down by this complexity, it doesn’t stop them entirely. What Hickey refers to in his talk as *complected* systems, the resilience engineering researcher David Woods refers to as *tangled*. In the resilience engineering view, Woods’s *tangled, layered networks* inevitably arise in complex systems.

Hickey points out that humans can only keep a small number of entities in their head at once, which puts a hard limit on our ability to reason about our systems. But the genuinely surprising thing about complex systems, including the ones that humans build, is that individuals don’t have to understand the system for them to work! It turns out that it’s enough for individuals to only understand parts of the system. Even without anyone having a complete understanding of the whole system, we humans can keep the system up and running, and even extend its functionality over time.

Now, there are scenarios when we do need to bring to bear an understanding of the system that is greater than any one person possesses. My own favorite example is when there’s an incident that involves an interaction between components, where no one person understands all of the components involved. But here’s another thing that human beings can do: we can work together to perform cognitive tasks that none of us could do on their own, and one such task is remediating an incident. This is an example of the power of *diversity*, as different people have different partial understandings of the system, and we need to bring those together.

To circle back to biology: evolution is terrible at designing *simple* systems: I think biological systems are the most complex systems that we humans have encountered. And yet, they work astonishingly well. Now, I don’t think that we should design software the way that evolution designs organisms. Like Hickey, I’m a fan of striving for simplicity in design. But I believe that complex systems, whether you call them *complected* or *tangled*, are inevitable, they’re just baked in to the fabric of [the adaptive universe](https://surfingcomplexity.blog/2020/01/19/there-is-no-escape-from-the-adaptive-universe/). I also believe that *easy* is such a powerful heuristic that it is also baked in to how we build and involved systems. That being said, we should be inspired, by both biology and Hickey, to have useful tools at-hand. We’re going to need them.

100% agree!

Much like biological systems, past a certain scale, human systems are no longer designed, instead they are

grown. The cost of redesigning a system with a long history often becomes too large, and that’s one more reason to try to keep them modular, and keep their components (and their interfaces) small when possible.
That said, we also get the opportunity (more often than nature?) to rewrite components and systems (e.g. for a new language, or a new platform), and in doing so, we often cut down the cruft. Hopefully these semi-regular resets help us evolve further.

easy is the opposite of arduous, tedioius, or difficult. so it’s not always “at hand” or “familiar.”

you can be familiar or expert at something that is still not easy to do for a variety of reasons. it is not easy for me to refactor poorly written, outsourced code. even though it is trivial for me to do so.

also, any system can be boiled down or zoomed in on further to be simplified or generalized. knowledge and wisdom allows one to describe complex systems simply and efficiently.

hyperaccuracy introduces category error, like someone responding to “how ya doin” with a trauma dump