Simple Made Easy by Rich Hickey

In the talk titled, “Simple Made Easy”, Rich Hickey emphasizes simplicity’s virtues over easiness’. He shows that while many choose easiness, they may end up with complexity. The better way is to choose easiness along the simplicity path.

The term “simple” is often erroneously mistaken for “easy”.

"Easy" means "to be near”, “to be at hand", or "to be approachable". The term “easy” is subjective and relative. When something is easy it’s familiar.

"Simple" is the opposite of "complex" which means "being intertwined" or "being tied together". Simple != “I already know what it means”. Simple != easy.

When a system is simple it has “one fold” or “one braid”. The system has a lack of interleaving in contrast with a complex, “braided” system.

Just because I can’t understand German does that mean German is unreadable? No, I just don’t know German.

“If you want everything to be familiar, you will never learn anything new.”

Reasonable software

If possible, simplify the problem space before you start.

Humans can only hold so much information in working memory. This fundamentally limits our ability to understand complex (braided) systems.

Your ability to reason about your program is critical to changing it without fear. Also, your ability to reason about your program is critical to debugging.

“What’s true of every bug in the field? It passed all the tests.”

Development speed

Rich made a great joke in this talk which also carries a lot of truth:

What kind of runner can run as fast as they possibly can from the very start of a race? Only somebody who runs really short races.

But of course we’re programmers and we are smarter than runners, apparently, because we know how to fix that problem. We just fire the starting pistol every 100 yards and call it a new sprint!”

Prioritizing ease often results in early speed that tapers over time. If you ignore complexity it’s inevitable that you will slow down over the long haul. Whereas prioritizing simplicity often starts out slower but allows us to pick up speed over time.

This line of thinking isn’t really applicable for trivial or throwaway projects.

The road to simplicity

The benefits of simplicity include flexibility as well as the ease of understanding, change and debugging.

A knitted castle is much harder to change than a lego castle.

How can we make things easy? We can bring something to hand by installing it. Or we can become familiar with something by trying and learning.

Compared to the complexity we can create, we’re very limited in our ability to understand it. We need to focus on making things easier to understand by simplifying them.

To gain simplicity:

• Choose simple tools
• Write simple stuff
• Simplify other people’s stuff (problem space or code)
  • Disentangle the complexity

“The bottom line is simplicity is a choice. It’s your fault if you don’t have a simple system.”

Choose simple tools

As programmers we tend to focus on the benefit of things rather than cost/benefit analysis. The first step to a simpler life is to choose simpler tools.

Sometimes we focus on experience of use of construct (a piece of syntax made up of smaller pieces) rather than the long term results of use like software quality and maintenance.

We must assess the constructs we use by their artifacts.

Write simple stuff

Your tools only get you so far. Programs are built by thinking more so than typing. We need to abstract for simplicity.

Form abstractions from related, small sets of functions. Strive to have many composable subcomponents. Favor rules and declarative logic systems over conditionals that make control flow complex.

Do not intertwine “what” your application is doing with “how” it’s doing it. If A does something and then calls B it’s too complex. Use a queue instead.

Contrary to popular belief, simplicity often means making more things, not fewer.

Don’t be fooled by code organization. Partitioning and categorizing our code doesn't imply simplicity. However, modular software is enabled by simplicity.

Simplicity Made Easy

Focus on the artifact (the program) rather than the authoring of the software.

Important questions when it comes to building software are:

• Does the software do what is supposed to do?
• Is it of high quality?
• Can we rely on it?
• Can problems be fixed along the way?
• Can requirements change over time?

The answers to these questions are what matters in writing software, not the look and feel of the experience writing the code or the cultural implications of it.

“Simplicity is the ultimate sophistication.” - Leonardo da Vinci