Simple Isn’t Easy (And That’s the Point)

Here’s a conversation I’ve had more times than I can count.

“Let’s keep it simple and just use the platform we already have.”

Sometimes that’s exactly the right call. But often, when you dig in, “simple” means “the thing I already know.” The platform we already have is going to be stretched, customized, and wired into places it was never meant to go. It’s easy to start with. It isn’t simple.

Rich Hickey made this point better than anyone in his talk Simple Made Easy. If you haven’t watched it, stop reading and go watch it. I’ll wait.

Two different words

Hickey’s distinction goes like this:

Simple is about the thing itself. Something simple does one thing and isn’t tangled up with other things. You can understand it on its own.
Easy is about you. Something easy is near at hand and familiar. You already know how to do it.

Simple is objective. You can look at a design and count how many concerns are braided together. Easy is relative. What’s easy for your team may be hard for mine.

The trouble is that we use the words as if they meant the same thing, and in a design review that’s dangerous. “Easy” gets the credit that belongs to “simple,” and complexity sneaks in disguised as convenience.

Where this shows up

Once you see the distinction, you’ll see it everywhere:

The Swiss Army platform. The CRM is also the case-management system, the document repository, and the workflow engine. Each extension was easy, since the platform was already licensed and the team knew it. The result is one system tangled up with four business domains, and nobody can upgrade it without a six-month regression effort. (I called this “overloading the switchboard” in my vendor warning signs post.)
The shared database. Letting the new service read straight from the old service’s tables is easy. No API to build, no contract to negotiate. It’s also one of the most complicated things you can do, because now two systems are tied together through a schema neither one owns.
The framework of the month. Adopting the new framework your senior developer is excited about can feel easy. There’s lots of energy and a slick getting-started guide. But you’ve added a new concept to the portfolio that everyone after them will have to learn. Dan McKinley calls this spending an innovation token, and you don’t get many.
The “temporary” integration. The nightly file drop to an FTP server was the easy answer in 2014. It’s still running. It now feeds three downstream systems, and the only documentation is a comment in a cron job.

In every case the easy option was easy at the start, and the costs came later. Easy is something you feel during the decision. Simple is something you benefit from for years afterward.

Simple usually costs more up front

This is the part people don’t like hearing. Simplicity usually costs more at the start.

Pulling two concerns apart means designing an interface. Building an API instead of sharing a table means agreeing on a contract. Choosing a dedicated tool over extending the platform you already have means a procurement process. Writing the small, focused module means thinking harder about where the boundaries go.

Fred Brooks split complexity into essential complexity, which comes with the problem, and accidental complexity, which we add ourselves. Most accidental complexity comes from choosing easy over simple, over and over, one reasonable decision at a time.

Questions to ask in your next design review

You don’t need a new methodology for this. You need better questions:

“Is this simple, or is it just familiar?” Make people say which one they mean.
“What is this tangled up with?” List everything the component has to know about. The shorter the list, the simpler the design.
“Could we explain this to a new hire in five minutes?” If not, why not? Is it the problem that’s complicated (essential), or the solution (accidental)?
“What does this cost in year three?” Easy choices are cheap in year one. Simple choices are cheap in year three.
“If we had to remove this, how hard would it be?” Simple things are easy to take out. Tangled things never leave.

Pragmatism still rules

None of this means the familiar choice is always wrong. Familiarity has real value. A team that deeply understands a boring tool will often beat a team fighting with a “better” one. Sometimes simple and easy point to the same answer, and that’s a great day.

The goal isn’t to reject easy. The goal is to stop letting easy pass itself off as simple. Call each one by its name, weigh them honestly, and then choose on purpose.