Simple vs Easy
During the first week of our cohort, we were tasked with watching a video recording of a talk by Rich Hickey, the author of Clojure, on the idea that Simple isn’t Easy. At first glance at the title I thought to myself that perhaps this was similar to design theory (and to an extent it is) but in software development, doing things the “easy way” can sprawl out into an complex braid of interleaved or braided things, which in turn creates more complexity in the software you are creating.
Easy for who?
This was an interesting concept — easy is not always simple. The word origin for the word easy, given in this context, is similar to adjacent or near at hand. Easy is an relative term that we seem to use to describe a familiar process to ourselves. For instance, the example given in the video was someone who has been speaking the German lanquage for a while might find that speaking German is easy — but that certainly wouldnt be considered easy for most of us in the English speaking world who havent even muttered a sentence of German in our entire lives!
This gave some real world examples for software development. The tools we are the most familiar with are the ones we will reach for first — no matter the level of complexity that is inherently involved with said tools — because they seem easy to use and we are familiar with their processes, gotchas and other nuances and the complexity involved.
Simple is objective. The concept of simple in the programming context I feel is a bit less obvious if one is always taking the easiest/fastest route to accomplish solving a problem. Simple things should be of one fold, or one braid, for example a function that might handle one specific task.
From Hickey’s point of view, simpler systems are slow to start while complex systems start off very fast because of the tools available that make the complexity ‘easy’ to attain and and execute on. He presented an experiential graph to show that over time things will slow down in the more complex systems, while the simpler systems will speed up over time.
This can probably be attributed to the maintainability of the code over time. If a program is made up of a bunch of smaller pieces that all compose together, then it would seem simple to be able to add a feature to the code and compose it with the existing code, rather than having to go back and refactor some inheritance tree.
Programming is already hard enough! It would seem silly to purposefully complicate things in your code, or not spend the time to work out a simple solution. I’m not yet experienced enough to determine whether or not some path is ‘simple’, and I think that I do have a tendency to overcomplicate things in some of the code that i’ve written. I do like the idea of a bunch of modular parts that do really specific things composed together to complete a larger task.
In this journey of becoming a professional developer, I hope that I am surrounded by folks who are a lot smarter than I that I can learn from. Sometimes the simpler, less obvious things just need a little light shown on them to make them more apparent.
If you’re interested in giving that talk a listen, hop on over via this link(1:01:26)
Type to you soon!