The talks I remember the most on QCon‘s second day are those from Rich Hickey. I was lucky enough to attend both the keynote in the morning (slides available) and the one about the modeling process (slides also available at the GotoCon website) in the evening at the London Java Community Group.
I was pretty amazed by the clarity of Rich’s thoughts in the Clojure documentation but I found a real visionary with the datomic service disclosure a few days ago. He’s a sort of philosopher, who tries to go very deep at first to grasp the essence of concepts like state, identity or time and then applies his thoughts to technology and I’m fond of this way of thinking and doing.
I already wrote about state, identity and behavior a few weeks ago. Here is a more general way to write about simplicity and is also the subject of Rich’s keynote at QCon : « Simple made easy ». Simplicity is a subject that fascinates me, as I see it as one of the ultimate goal in my design activities. In the following sections I will humbly mix my thoughts on that subject (sentences starting with « I ») with the ones from Rich (sentences starting with « Rich »).
Simple and Easy
Rich started by talking about the core and boundaries of these two words:
- Simple : one fold, which is not composed
- From the latin simplicem, "without a fold"
- Is the opposite of complex
- It is an objective concept that is independant of the human observe
- Easy : lie near
Complication or complexity?
As a first step to grasp the concept of « simplicity » I started to look at what the opposite, complexity, is. So I separate at first complication and complexity:
- Deterministic, has a lots of details and connections, but with linear « cause and effects »
Finally, even though it’s interesting from an intellectual point of view to separate complication and complexity I think we can just use the following definition:
Complexity is a measurement of how difficult it is for someone to understand how a system will behave or to predict the consequences of changing it Therefore the latter definition is relative to the subject trying to understand a system, so I think that what is pertinent to analyze here is the subject’s perception of complexity.
What makes a system difficult to understand?
High level of variety in its components
Lack of order
Same relationship between the elements but some organization (partitioning) was added to the left
High degree of connectivity
Which one do you prefer to work with? :-) But is simplicity only a lack of complication and complexity? It’s a good start (high order, low connectivity and low variety) but I think there is something more to it: *simplicity is also defined by what you add with clarity, purpose, and intentionality *(look at the DDD intention-revealing interface pattern). I think the most difficult part of simplicity lies in the latter.
Complexity and Simplicity toolkit
Rich’s morning talk was a praise to Clojure and a line of arguments about why Clojure is better on simplicity and easiness. Rich reborns an old english verb « complect » : « To join by weaving », and compare complexity and simplicity constructs to what they complect. Actually, it was a confrontation of the OOP/imperative way of thinking versus the functional one with the exposure of the different concepts on each side :
Complexity tool kit
|State||complects||everything that touch it|
|Objects||complects||State, Identity, Value, Operations|
|Methods||complects||Function and state, namespace|
|Syntax||complects||Meaning (derives meaning), order|
|Switch/matching||complects||Multiple who/what pairs|
|Variables||complects||Value and Time|
|Imperative loops, fold||complects||What and How|
|Actors||complects||What and Who|
|Conditionals||complects||Why and the rest of the program|
|Construct||Get it via|
|Values||final, persistent collections|
|Functions||a.k.a stateless methods|
|Data||Maps, arrays, sets, XML, JSON etc.|
|Polymorphism a la carte||Protocols, type classes|
|Managed refs||Clojure/Haskell refs|
|Declarative data manipulation||SQL/LINQ/Datalog|
It appears that the Clojure concepts have all the simplicity labels :-). Nevertheless it’s a good kick in the ass of the OOP approach.
What brings simplicity in our programs?
- Composition of simple components together
- This is really the fundamental way to have a simple design in a direct application of the Single Responsibility Principle.
- In tune with the Unix philosophy that composes small programs (cat, grep, sed, awk) and link them together through text interface (the pipe). Actually, I think each point of the Unix philosophy helps bringing simplicity in every design.
- Modularity by partitioning or grouping
- But be careful, grouping and partitioning are enabled by simplicity, not by the opposite.
- State always bring complexity
Example of incidental complexity with the « order » concept
Then Rich talks about the « order » concept, which gives a concrete example of one that brings incidental complexity and infects a lots of our usual programming constructs without any usefulness. Why « order » brings incidental complexity? because modifications are inhibited: a change in the order impacts the usage others have on the collections.Hence we find the « order » concept in the following constructs on the left while the construct on the right side fulfill the same needs but without that over-added « order » concept.
Order in the Wild
|Positional arguments||Named arguments or map|
|Product types||Associative records|
|Imperative programs||Declarative programs|
|XML||JSON, Clojure literals|
Why take all this times to write about simplicity in what can be seen as very philosophical? because simplicity is a key concept and a key skill to design our softwares, not only in their technological aspects but very firstly in their domains. Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not dealt with in the design, it won’t matter that the infrastructural technology is well-conceived. A successful design must systematically deal with this central aspect of the software Eric Evans, author of Domain Driven Design. « Simplicity » and « Common Sense over Common practice » was also the corrolary of the « test considered harmful » and « ORM OMG ! » that were higlighted several times during the conference. What I like the most in QCon is the « think differently » that I could feel in some talks given by opinionated people. And after that exposure I started looking at things and thinking differently, so thank you Rich for having given me that! Other write-up about that second day at QCon :