English version / Version Française ici
What devs can learn from Giants.
2009, Berlin: Usain Bolt beat the 100m Mens World Record in 9.58 seconds. Please take a look at how simple it seemed for him:
2012, Beijing: Lang Lang plays La Campanella. It looks so simple for him it actually looks like he is playing around:
Despite the underlying complexity of these crafts, despite all the time and efforts that have been required to reach their top level, when you take a look at the way they do stuff, it actually looks simple.
Too often, we think that what looks simple isn't optimized
Long before my first articles on Dev. Simplicity, I had many talks with devs who master current complex modern frameworks such as Angular or React, as well as their related environment tools.
Most of the time, they didn’t agree that development will and should become simple. To them, mastering tech is naturally complex and it should stay this way.
They were saying it is part of our job to keep learning stuff in order to keep up with modern tech evolutions. Because this is how apps can evolve and can keep being optimized.
Most of them didn’t feel the need for tools or frameworks to become simple. We should adapt. We should learn. Because as devs or as engineers we can.
Top-level code is simple code
Usain Bolt and Lang Lang reached the top-level of their fields.
When Usain Bolt runs, it looks simple, but it’s not. When Lang Lang plays, it looks simple, but it’s not. Under the hood, it has been very complex for them as they’ve been learning and training for thousands of hours.
It is possible to imagine simple, top-level dev tools, that would allow us to reach top-performance as well, by generating the most optimized apps. First-class tools that look simple, but which are not. Tools that we can operate in a simple way, but which are performant because of their underlying complexity.
Their complexity should stay under the hood, and most devs should not have to deal with it. It is possible, for example, if we use abstraction and if we separate app description from app engine.
You are not a bad developper for prefering simple, highly-abstracted and readable syntaxes and patterns, over overly-complex and mystified trendy syntaxes and patterns. Because if tools were well-thought, they could offer both simplicity and performance. It is technically possible.
And besides optimization, Simplicity means better readability, better maintainance, better evolutivity, better teamwork, less training time, and less overall development cost.
But it also leads to something more.
Something you’ll find in simple people’s way-of-being.
Something you’ll find in rare mathematical demonstrations.
Something you’ll find in programming, in science, in fashion, or in design.
It leads to Elegance.
Top comments (2)
I played acoustic guitar for many years. All of the good players made it look simple. Hidden behind all of that were hours and years of continual improvement. Software delivery is like that, first deliver simple and continually improve each iteration should focus on one single aspect.
I understand. Mastering guitar takes time and efforts. I agree on the fact dev is like you describe nowadays : first deliver is simple, and then you improve apps little by little. My point is that we can change paradigm. If we separate app descriptions from app engines, we could benefit from the thousands of hours of core improvement, spent by the devs who actually made the dev tools. Therefore making optimized apps can become simple from the first delivery.