Resisting simplicity

As much as we admire simplicity and strive for simplicity, something in us isn’t happy when we achieve it.

Sometimes we’re disappointed with a simple solution because, although we don’t realize it yet, we didn’t properly frame the problem it solves.

I’ve been in numerous conversations where someone says effectively, “I understand that 2+3 = 5, but what if we made it 5.1?” They really want an answer of 5.1, or maybe larger, for reasons they can’t articulate. They formulated a problem whose solution is to add 2 and 3, but that formulation left out something they care about. In this situation, the easy response to say is “No, 2+3 = 5. There’s nothing we can do about that.” The more difficult response is to find out why “5” is an unsatisfactory result.

Sometimes we’re uncomfortable with a simple solution even though it does solve the right problem.

If you work hard and come up with a simple solution, it may look like you didn’t put in much effort. And if someone else comes up with the simple solution, you may look foolish.

Sometimes simplicity is disturbing. Maybe it has implications we have to get used to.

Update: A couple people have replied via Twitter saying that we resist simplicity because it’s boring. I think beneath that is that we’re not ready to move on to a new problem.

When you’re invested in a problem, it can be hard to see it solved. If the solution is complicated, you can keep working for a simpler solution. But once someone finds a really simple solution, it’s hard to justify continuing work in that direction.

A simple solution is not something to dwell on but to build on. We want some things to be boringly simple so we can do exciting things with them. But it’s hard to shift from producer to consumer: Now that I’ve produced this simple solution, and still a little sad that it’s wrapped up, how can I use it to solve something else?

Related posts:

One thought on “Resisting simplicity

  1. There’s a difference between “true” simplicity and “perceived” simplicity.

    The first is generally brief, without fluff.

    The second is where “elegant” plays a role. A rather involved process can be made “simple” by clean design and implementation, and especially by great documentation.

    In both cases, someone reviewing the solutions could describe them both as “fairly obvious” (typically with 20:20 hindsight).

    In my case, “truly” simple solutions are self-explanatory Bash one-liners. Elegant solutions are a page or two of Python. The “so not simple” solutions are in C/C++, generally optimized for both speed and space.

Leave a Reply

Your email address will not be published. Required fields are marked *