Simplicity Matters - Rich Hickey

Keynote talk from Ruby Conf 2012 - simple vs. easy, programmers vs. programs, and how to choose simplicity

Watch on YouTube:

“Simplicity is prerequisite for reliability” – Edsger W. Dijkstra

Word Origins

simple (sim-plex) - one fold/braid/twist vs. complex - combine/braid many things

easy (ease < aise < adjacens) - “lie near” vs. hard


but not

this is about lack of interleaving, not cardinality


you can look at this, and see how things are twisted together


near at hand

near my understanding/skill set

near our capabilities - can install something complex, but I don’t understand it

most difficult are things that are complex, outside of our mental capacity

Too hard to think about

we don’t often talk about this

there’s a limit to what we can think about

relative, subjective

something that is hard for me may be easy for someone else


we can only think about a few things at a time

intertwined things must be considered together

complexity undermines understanding

if we don’t understand something, how can we reliably change something, make it better?


as you progress with a project, the elephant in the room is the software you’ve already written

moving forward, you have to change that elephant, make it do more, better

challenge becomes understanding it

whatever processes you use, tests, etc. you will be dominated by complexity

Simplicity = Opportunity

simplicity is not just defensive

buys you opportunity with your designs

architectural agility wins, otherwise you’re pushing the elephant, waste lots of time

design is about taking things apart

can repurpose, substitute, move, combine, extend

simplicity buys us ease and agility

“LISP programmers know the value of everything and the cost of nothing” – Alan Perlis (old dig at LISP)

“Programmers know the benefits of everything and the tradeoffs of nothing”

fixated with our own ease of development

but we should be thinking about the software we’re making

Foo Fighters

if they wanted easy, they would skip learning instruments

and be the “kazoo fighters”

Programmers vs. Programs

there’s a certain conflict here (but there need not be)

focus on ourselves

be careful what you wish for

rather than focusing on the programs

when choosing something, are we saying “I like this because it’s good for me personally right now”


hairball - complex thing all tangled together

complect - to interleave, entwine, braid

“I went on vacation, and now it’s all complected”

don’t do this!

the more you do of this, the more difficult it is to make reliable software that you can change and enhance

Making Things Easy

(not saying that easy is bad)

  1. bring to hand by installing - use a new thing, something that is novel
  2. become familiar by learning, trying

if you want everything to be familiar, you’ll never learn anything new

  1. what about mental capacity? not going to move very far

is there a “get smarter for dummies” haha

we’re all not much smarter or dumber than each other

when tackling a complex problem, have to bring it closer to where we are that problem has the inherent complexity that it has make our implementation of them is as simple as possible

to make things easy, need all 3 of these things, not just the first 2

“We can be creating the exact same programs out of significantly simpler components”

can use dramatically simpler:

why aren’t we?

What’s in your toolkit?

lots of choices that we can make

Complexity Simplicity
State, Objects Values
Methods Functions, Namespaces
variables managed refs
inheritance, switch, matching polymorphism a la carte
Syntax Data
Imperative loops, fold Set functions
Actors Queues
ORM Declarative data manipulation
Conditionals Rules
Inconsistency Consistency

“Simplicity – the art of maximizing the amount of work not done – is essential” – Agile Manifesto

wrong - simplicity is not about you, it’s about the thing you’re making

doing the job of simplifying things is hard work

BUT, there’s a huge payoff - the person with the simpler system will be able to effect the greatest change with the least work

“Simplicity is not an objective in art, but one achieves simplicity despite one’s self by entering into the real sense of things” – Constantin Brancusi

simplicity is not an objective - it falls out of trying to pull things apart into their essential natures

now for a couple examples of thinking about simplicity in context

Lists and Order

is there a problem? we all know what lists are

if order matters, complexity has been introduced into the system

Why Care about Order?

“We don’t do that”

well, let’s see about that…

Order in the Wild

Complex Simple
Positional arguments Named arguments or map (there is a tradeoff here)
Syntax Data
Product types Associative records
Imperative programs Declarative programs
Prolog Datalog
Call chains Queues
XML JSON, Clojure literals

Maps (hashes), Dammit!

Information is Simple

the information non-problem

use a hash instead


you still have to pick a representation with encapsulation

Wrapping Information

information class:

IPersonInfo {
  ... more verbs and crap ...

service based on that:


what kind of problems does this create?

Can you move it?

litmus test:

hard to do this when you’re sending verb-oriented things around

Subsystems must have

build these object-very things inside our programs

as soon as we move it to a server, using REST and JSON, data :)

if those ideas are good there, why not inside your program?

if you’re programming with data all along, moving things around is much easier

Simplicity is a Choice

(wrapping up)

simplicity is not something that falls out of tooling, or practice, or whatever else

this is the most important work we do - doing this makes everything else substantially and deeply easier

your “reliability” tools don’t care if you program is simple or not

choose simple constructs

Simplicity Matters

complexity inhibits understanding

simplicity enables change

simplicity = opportunity

go make (simple) things!