Notes from Rich Hickey’s talk on simplicity at Strangeloop 2011.
The video is now available here.
Word origins:
- Simple = sim – plex = one braid
- Easy = adjacent = lie near
- Simple means having one of something, one braid, one fold, one role, one concept, one task, one dimension.
- Simple can involve many things, but not having interleaving.
- Simple is an objective notion.
- Near, at hand.
- Near to our understanding–being familiar.
- Near to our capabilities. We don’t like to talk about this because it tramples on our egos.
- We are far to interested in things being easy. This is to our detriment.
- Easy is relative (unlike “simple”). Music and German are hard from some and easy for others.
- We become to infatuated with things being easy instead of being simple.
- Long term use is a better indication of simplicity and helps keep use from focusing on things being easy.
We can only hope to make reliable those things we can understand. There is a limit to how much we can keep in our mind at the same time. Intertwined things have to be considered together and this taxes our brains. Fewer “braids” means less complexity and less complexity means we can hold it in our minds better.
To change software requires analysis and decisions. You must be able to reason about your program to be able to reliably change it.
We say, “I can make a change because I have tests.” Who does that? Who drives their car around banging into the guard rails!?
Easy things make us feel like we are fast.
What type of runner can run full speed from the very start of the race? Thats right. Someone who runs very short distances. But as programmers, we are smarter than that. We just fire the starter pistol again every 100 yards. I don’t know why runners haven’t figured that out.
Ignoring complexity will slow you down if you aren’t just doing a very small project.
There are many constructs that are easy to use, but are very complex.
Benefits of Simplicity:
- Ease of understanding
- Ease of change
- Easier debugging
- Flexibility
- More independence for change.
Making Things Easy:
- Making it “at hand” by bringing it into our environment–installing it.
- Become familiar with it by learning it.
- There is a mental barrier. We can’t really get much smaller.
We are all very limited compared to the complexity we create. The difference between a really smart programmer and an average programmer is minimal–no one can really understand all of the complexity we can create. A juggler can juggle 3 balls. A really good juggler can juggle 9. No juggler can juggle 90 or 900.
Everyone has seen parenthesis, but they haven’t seen it on THAT SIDE of the method. Thats crazy!
Parenthesis are overloaded in lisp. They do several different things so they are complex. By removing this complexity the ease problem is back in the domain of what we can change.
Everyone is happy to grab benefits of new tools, but no one takes the time to see if there are any trade offs.
- Complect = braid together.
- Compose = place together.
We can write modules that are completely complected. What are your modules allowed to “think” about. Just partitioning doesn’t give you simplicity.
Having state is never simple because it complects value and time. It is easy, familiar, at hand, etc. The only way to get rid of state is to put it in a box that gives you a functional interface where you always get the same output with the same input.
Simplicity is a choice. It is your fault if you don’t have a simple system.
