Simple and Easy: A Vocabulary to Describe Software Complexity 23 March 2014

Recently I was directed to an enlightening presentation called Simple Made Easy by Rich Hickey, the creator of Clojure.

Because it’s really difficult to justify asking someone to watch an hour long presentation just to be able to use the same terminology, I’m publishing some notes here in a more easily digestible format. This is not a direct transcription, but more of a selective overview of the parts I consider the most important.

I still highly recommend that you watch at least the first half of the presentation itself. While it does become a tad Clojure-specific at times, on the whole it remains broadly relevant. There are also slides from the presentation up on slideshare, from which I have taken some screencaps for this post.

Terminology

Rich starts the presentation by examining the latin roots of the terms, to illustrate their meanings in this context.

sim·ple

cf. sim- plex

one fold/braid

eas·y

cf. ease < aise < adjacens

to lie near

Simple is traced to simplex, a combination of sim- (meaning one), and plex (meaning fold or braid). He describes it as a piece of string, which if it only had one fold or twist, would still basically have no twists. The opposite of simplex is complex, which literally means ‘braided together’. He describes it as having a couple or pieces of string that have been braided or knotted together.

Easy, when traced down to the original latin adjacens, means ‘lying close by’ or ‘to lie near’. In the sense of being having something be within reachable distance. The opposite of easy is hard, which doesn’t actually have a specific meaning here beyond the general usage of the term.

Simple vs Complex

When we look for things that are simple, we are looking for things that have one of something, such as having one role; fulfilling one task or job; be about accomplishing one objective; be about one concept (like security); or be about a particular dimension of a problem you are trying to solve.

Simple doesn’t mean that there is just one of them, or that is an interface that only has one operation. It is about the lack of interleaving, not the cardinality.

Simple is Objective: To see if something is simple, you can go look in the code and see whether there any connections, or any place that it twists with something else. If it isn’t interleaved, it’s simple, otherwise it’s complex.

Easy vs Hard

There are several different senses in which something can be easy or hard.
Rich categorizes them in the following ways :

Near, as in at Hand

On our hard drive, in our toolset or IDE... just generally available.

"Oh, library X includes that so we might as well use theirs!"

Near to our Understanding/Skillset

Familiar, or closely enough related to allow for knowledge transfer.

"I already know Library Y, so I will just use that!"

Near to our Capabilities

Whether it is within our ability to reason about, how 'smart' we are.

"What the hell is going on in Incredibly Complex Topic Z, I'm so lost!"

Easy is Subjective: For something to be easy to me, it needs to be near to me, so it is relative to how available and understandable it is to me, or whether I am even capable of understanding it.

Stuff that is easy to me, in the familiar sense, might not be easy to you. Stuff that is easy to you, in the capability sense, I might not even be able to comprehend.

Constructs vs Artifacts

We program using constructs. The programming languages, libraries, and tools we use are all constucts. All of them also have these characteristics of being simple or easy, in and of themselves.

The programs we build are the artifacts. All of the characteristics such as whether it runs, whether it performs acceptably, or whether we have the ability to change it… those are all properties of the artifact, not the construct.

We tend to focus on our experience from using the construct, by emphasising how convenient it is for the programmer, or how easy it is to replace programmers on a project.

We should be thinking about the artifacts we produce and how long term use of a construct will affect software quality and our ability to maintain or change the software over time.

Conclusion

We are going to stop here at about 25 minutes in, mostly because it’s a really dense presentation with a lot of concepts, and these are the most important ones I needed to get across.

This article originally had 2 parts, but I felt it was better to just keep on updating this document with the terminology, and moved the effects of complexity to the second part in the series.

I highly recommend that you watch the presentation itself, if you want to learn more.