Case Statement

Simple Ain’t Easy

We watched another video during our Lunch and Learn Fridays. In this one, Rich Hickey masterfully draws the line between simple and easy. It’s been over a month since I first saw it but his words are still burning in my mind.

Hickey’s talk focuses on two common words; simple and easy. Think about easy as near at hand or familiar and simple as uncomplicated. And while we rarely think about the differences between the two, it turns out that in software thinking about simplicity as separate from ease is quite important.

The question that I keep asking myself is why is it so hard to make something simple?

Easy: near at hand

In software, easy is king. There’s a sense that if your language, tool, or project can’t demonstrate its superiority in the first paragraph of its website, then it will languish and die.

So the next time we start a project we ask ourselves, what’s easiest? We remember the latest hyped thing that promises to get started in five steps which is one less step than the previous hyped thing.

I’ve seen many arguments for a tool based on how easy it is to use. I’ve also seen those arguments tumble months later when the tool has had to be monkey patched to hell in order to fit requirements. This happens so often that it feels inevitable, but it could be that ease is just a really poor justification for using something. If anything, thanks to Hickey, I can now articulate why it’s such a poor choice.

Simple: one braid; uncomplicated

So, Hickey’s argument is that if you confuse easy with simple, your project will become complicated, complected and intertwined without hope. On the other hand, if you understand the difference and focus on simple, you will make better decisions that will create a healthier project. The solution to maintainable and sustainable software is simplicity not ease.

Just try to do this. People have been preaching for simplicity forever. We have tools, practices, and laws that promise to decouple concerns. Yet when Hickey asks his audience if they’ve ever worked on a simple project, properly modularized and abstracted, he needs to raise his hands twice because no one else had seen such a thing. Are most of us too stupid to write a simple system? Are we too lazy to use the tools at our disposal?

It’s actually not difficult to spot complicated code. In the past, if the code was also written in a consistent, familiar way I’d let it go and move onto the next thing. Recently I’ve tried to tackle my complex code and I find that I quickly run into the framework’s complexity. There are ways around the problems but they’re ugly or hard. Seeing code with this new perspective is painful.

Yet, when I’ve taken the time and have been able to simplify a problem, I find that I’m rewarded with that wonderful, fleeting feeling that what I’ve created is correct.

No Pain, No Gain

I feel that the problem is that the tools we currently have to tackle simplicity are not easy. It takes time and effort to grok design patterns. It is hard to follow the law of demeter if everyone around you is building things the easy way. It is far easier to create mockeries if you’ve never used dependency injection. Hell, it’s even easier to complicate unit testing with maintaining a test database and fixtures.

There are tools that provide simplicity, but they rarely reach that tipping point of mass adoption.

So please, watch the video, simplify your code, call out libraries and frameworks that are easy but complicated, and help build new tools that focus on simplicity. Make it simple then make it easy.