In his talk, Rich Hickey explains the difference between simple and easy, and suggests how to identify where we are adding complexity to our software, and how we could make it simpler and easier to develop. Rich explains that composing simple components is the key to robust software.

Here's what I took away:

In software, simple means not having interleaving objects and threads; its objective because things are either twisted together or, they aren't. On the other hand easy is relative, and might mean something is available (pre-installed software for example), familiar, succinctly described, or obvious to use. You could say that simple is the opposite of complex, and easy is the opposite of hard.

Every time I make a decision which makes my code more complex, I'm creating cognitive load for future me and any other developers who are sharing my codebase.
Say you discovered a bug in a hypothetical program which lets users identify trees in the world, and record them on a map. If you need to learn about a bug in the map-plotting code but that code is twisted with the gnarly branches of the tree-labelling code, you not only need to learn about map-plotting to fix your bug, but you need to know about tree-labelling too.
When your intertwined complexity becomes more intwined - with users and species and GPS... this information becomes more than anyone could hold in their head - so how can you make a decision about what change you need to make?

As complexity grows decisions become more difficult. Ignoring complexity will slow you down as time passes because you will be restricted in what you can do, and untangling that complexity will dominate your tasks.

 Identifying complexity

Where there is order, there is complexity. If the order of things matters, that might be a bad sign. Thinking about what data structures you use, the order of method parameters, daisy-chaining method calls... order binds one thing with the next which creates complexity.

I came across this complexity in a ray tracer project I've been working on (ray tracing is a way to render images); there was an implicit order with a function which used width and height parameters - I was finding my calculations didn't make sense because the order of width and height varied across my code base, it related to my outside assumptions of width coming before height and the way I'd written the code where I hadn't thought carefully about what order I was using in my tests. Fixing the resulting bugs so the order was consistent was tricky, made harder because the values were of the same type! The parameter order should not be coupled with my method, instead they could be abstracted away so that the method took only one argument: the result of the interaction between width and height (maybe we can call that the area or the sum). This removes the need for passing in arguments in any one order.

Simplifying complexity

Here's some suggestions to reduce complexity in your code:

• Use associative structures like maps instead of lists which bind you to order, and choose data structures that let you use your data without polluting it with side-effects
• Use data files like JSON to hold data, rather than document files like XML which can add unnecessary meta-detail
• State is never simple because it is not stable and it changes, so use the final keyword whenever possible
• Modularising your code can enable simplicity, but it doesn't remove coupling completely (you will still need dependencies and these are important in holding your system together). Modularity isn't inherently simple but it does reduce complexity.

🔥 This talk was recommended to me by @quii who said that every time he watches this talk, he takes something new away from it.

Please share in the comments if you took away something from this talk; I'd love to hear what you thought!

🔈 Rich Hickey, is the author of Clojure: a dynamic, general-purpose programming language described as a dialect of the Lisp programming languages. InfoQ describes him as an "independent software designer, consultant and application architect with over 20 years of experience in all facets of software development."

✨ Watch Rich's full talk Simple Made Easy recorded at QCon 2011, at infoq.com. Running time about 1h.