Notes on Simple made easy – Rich Hickey

Simple vs easy.

This is such a cool idea. It’s one of those that is right under your nose so that you would never have taken a breath to acknowledge it.

We generally use simple and easy interchangeably. But building simple software is extremely difficult. Not easy. Simple means that two things are not intertwined, complicated means many things intertwined, be that a conflation of two or more concepts, or typically in web dev, entangling the state or design of two separate concerns.

Easy means something is within reach. This may be physically, but more aptly, Hickey speaks of something being within reach of our familiarity. For example, we might choose to program something in Ruby because we know Ruby fairly well. It is familiar. But it might be that that particular program would be better written in Go, but because Go is not within reach, we choose Ruby. UH OH. Warning! This program will not be simple.

Sadly for us developers, business owners are generally plussed about easy. Not simple. What an easy mistake to make 😉

We rarely speak of being incapable of doing something, we rarely say that that something will require an expert in X. Easy is a relative term. What’s easy for me might not be easy for you and vice versa. For example, neither myself or Rich can speak German very well. However, my friend Mike can speak German no end. And so it might be for solving that concurrency problem you have with your database. On the bright side, it’s only a matter of you learning what will eventually make that problem an easy one to solve. But please, please acknowledge that!

When it comes to complexity, we all have pretty much the same appetite for it. A program can become very complex, very quickly. We can only hold a few ideas in our head at once. Complex programs become unpalatable and incomprehensible for us. However, even if we could hold lots and lots of things in our head, I propose that our programs would only be EVEN more complex. And this due to the constructs of our programming tools.

Let’s talk about constructs of a programming language. Rich Hickey makes the point that all our end-users care about is the artifact we produce, not the sexy code we write. Therefore our programming tool should base its constructs on the artifact that we produce. What’s the point of having an abstraction over data if it’s going to make things more complicated? Work with the damn data that’s underneath. Not some horrible object which is an abstraction over it. H proposes that if a program works well, it’s because the constructs in the language were simple, conversely complex objects add incidental complexity, they’re another layer that you have to understand before you understand wtf is going on. Boo.

In this vein, modularity doesn’t imply simplicity. You can have a bunch of classes that obey SRP but you end up with an onion design where you have to chase through all these classes that call each other and “nicely abstract you away from the implementation”. Well what if I want to change your smelly implementation, you salmon!?! “Abstraction” is not “hiding stuff”, it is encapsulating stuff. Similarly, state sucks. It means nothing is a value. A variable conflates value with time. You have created a big old system, then some bug creeps through, through all your tests and all your agile safety nets. Oh noes, let’s recreate the state of the system that caused that bug. Oh wait, it’s really really complicated to do that.

On a similar note Rich talks about tests for a bit. Tests are like guard rails on a car. They DON’T guide you, and you don’t drive your car by smashing into stuff and letting the guard rails tell you, “you’ve hit something again pal, turn around”. And finally, are those test suites and refactoring tools going to help you unravel your intertwined complexity? No they’re not. Complexity is a design level thing. You need to work with a fundamentally different programming tool. You can’t just test every little thing that might go wrong. And it’s totally boring doing that. Oooh I love TDD. I write tests to ensure that a joke is funny before I say it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s