November 25, 2021 // dev , kintsugi , philosophy
Filed under dev
Someone on Hacker News, on a discussion about how perfect systems don’t exist, dropped this:
A great skill I have been developing as I mature is the ability to look at a seemingly suboptimal implementation I receive and not be appalled by the perceived sub-optimality but rather appreciative of the history that is embedded in the little details. For me, any system producing correct and useful results is perfect under the constraints of its implementation. Even if the developer was not great, someone was great enough to mitigate for it. I have seen many such ugly, perfect systems.
I call that “software kintsugi” I replied, though it isn’t exactly how I would describe it, and it itched me enough to write this scratch.
Kintsugi is the art of fixing pottery with laquer, usually mixed with gold, and a philosophy that embraces the breakage as integral part of the object, rather than a stain to clean, an imperfection to correct, or something that makes the object any less valuable.
While breakage doesn’t really translate directly into anything in the software itself, or computer systems overall (let’s leave literal understandings aside), an architecture might have some fragility in it, which doesn’t mean the software itself will break, but it will fail to do what it’s supposed to, and not because of its own faults, but because of external factors. Like a tea bowl when it breaks.
It’s recognizing and acknowledging this fragility (either by studying the system or by watching it fail) and mitigating these behaviors what I’d call performing software kintsugi. The ability to identify and learn to love these mitigations in the architecture of the system is appreciating software kintsugi. Oftentimes these mitigations might look like strange architectural decisions, or high level code that isn’t all that obvious when you first look at it, and its meaning only becomes clear when you try to clean it and make it proper.
This is different from bug fixing. Bugs are things that are wrong to begin with, result of working while tired, unclear specs, lack of reviews, or whatever is to blame in their particular instances. They’re to be corrected, perfectly: they were never supposed to be there, they’re warts to remove, jagged edges and burrs to polish.
Software kintsugi is more about the general direction the system takes towards a particular static target of the desired functionality, rather than the usual lifetime of a system, that needs to be changed according to the requests of clients or business needs. It’s guided evolution in aims to stay close to that desired and already achieved goal. A bowl is meant to stay being a bowl, it’s not supposed to turn into a plate or a vase, or to become square, or bigger or smaller. While the target is static, the world is dynamic, which is what makes it break.
It usually happens, but not only, when a system is to be kept because it just works, or when early architectural decisions weren’t sound and they need to be worked around. Oftentimes the cost of replacing, rewriting, or even refactoring is too high, and maintainability, while important, isn’t all that critical as the system already does what is wanted from it. It still needs to carry on with the times and adapt to an ever changing world, to keep serving the same requests, or tea, as always before.