You grow bonsai and bonsai grow you

Grown inspiration for software and people

At the beginning of the pandemic, I discovered bonsai as a new hobby. Daily care for my seven little trees has also brought inspiration for my daily work as a software developer. In this article, I’d like to look at some similarities between bonsai and software as a reflection upon our work.

At first glance, bonsai and software don’t seem to have much in common. The word bonsai 盆栽 comes from Japanese and is composed of two characters: “shell” and “plant”. It originates from the Chinese gardening art Penjing 盆景 (“pot” and “landscape”) and found its way to Japan via Buddhist monks. There, it developed further into an independent art form, spreading to Europe and the rest of the world through Japanese immigrants in America.

What are bonsai?

Bonsai are plants placed in pots, combined with Japanese aesthetics and philosophy. The basics of bonsai are the same as gardening: water, fertilizer, fungi, pests, seasons, pruning, and constant care.

The common aspect that bonsai and software share is that bonsai grows organically and software grows semi-organically. Both are worked on by humans. Although we like to call ourselves software engineers, we are humans first. We develop software with our brains and interact with other humans on the same team, with other teams, or teams from other companies. These human relationships are reflected in our software’s structure, and in the mindset of multiple authors who have taken them on over time.

Impermanence

The insight that everything is subject to permanent change is often attributed to Eastern philosophy, but it also has roots in the West. The aphorism “panta rhei” (everything flows) is attributed to Heraclitus of Ephesus. Goethe also directly refers to it in his work “Dauer im Wechsel” with “Ah, and in the same river you do not swim for a second time”. In Japanese Buddhism, impermanence is found as 無常 (“Mujō”), where it also strongly influences aesthetics.

Bonsai are plants. They live and change, or else they die. In spring, new shoots grow, branches become stronger, and flowers open. In summer, plants go dormant because of the heat. In the fall, new growth stabilizes. Leaves change color and fall. The tree prepares for the cold. In winter, there’s a change from activity to dormancy. Our native northern hemisphere species go dormant to withstand the cold.

Software is also subject to permanent change because it must adapt to its environment. Users want new features. The operating system, base image, or programming language receive updates. Vulnerabilities are found and need to be fixed. A new legal situation requires changes to data management.

Clinging to the idea that our software will ever be perfect and finished only leads to disappointment and unnecessary stress. We shouldn’t obsess about having written or being able to write perfect code forever. It can only ever be the current, best code that we can develop for our current context. But like all things, context will change, so our software must change. Conversely, we always have the chance to improve our code and make it better suited for the current situation. We always have the opportunity to write the code that’s currently the best and grow in our own capabilities.

Grown software had to evolve in many contexts over the course of its lifetime. To the best of our knowledge, it’s been adapted to fit the restrictions and circumstances similar to the ones we’re working under now: limited time, limited budget, limited knowledge, and constant change. The code’s previous authors probably did their best under adverse circumstances, just like we did, until they left the project. They left us their work as a “legacy”. Control

With bonsai, we have no control over where the next branch will start growing. We can decide which branches to cut and which to leave on the tree, but once the cut is made, we can’t go back to the previous state. A branch also doesn’t grow back in the same place, and never in the same shape as before. We can guide branches with wire to grow into our desired shape, but if we bend them too much and exert too much control, the branch will break and die. If we wrap the wire too tightly around the branch or leave it on for too long, it will grow into the wire, take damage, and like my maple, get scars that remind me to this day of the importance of recognizing and practicing correct measure and timing.

With code, it’s a little different. There, we have version control and we can jump back to previous versions. Nevertheless, we can’t always use all old versions in production again. Some programming language versions no longer work in the environment that we’d need to install them in today. Some libraries that we used at the time, we can no longer use because of security vulnerabilities.

We also have little control over which features our customers will want next, or which regulations legislature will deem sensible. Likewise, it’s not in our control where the next bug in our code will be, or where the next security gap will be found. It’s just fairly certain that it will happen sooner or later.

Uncertainty and frustration

Impermanence and lack of control lead to uncertainty and frustration. Pests and fungi attack my bonsai and harm it. I mistake leaf discoloration from the summer heat for fungus and treat my bonsai with fungicide, weakening it. I cut one branch, but the rest gets dieback because I cut too much instead of leaving room for a stump. Roots rot because I watered it too much. My wonderfully blooming, crabapple bonsai suddenly stands in unexpected spring snow. If you’re holding your breath now: The little tree is fine, but there’s no guarantee that snow won’t fall in the spring again.

In the middle of the deepest project stress, one week before the deadline, a critical vulnerability is found in the logging framework. We have to adapt all modules in all of our projects. In some of them, the framework is included only through transitive dependencies.

We worked long and hard on a new feature, but due to our customer’s strategy change, it doesn’t get used at all. Customers or other suppliers use our API differently than we envisioned. I come into a ten-year-old project whose code presents technical and organizational problems that I’ll never completely solve because it’s simply too much work for one person.

By now, I wonder if my earlier anger towards authors and code quality wasn’t an expression of my helplessness. I simply had too little practice and experience with evolving code in small, safe steps until it was good enough for current requirements. Likewise, I had little experience with complex organizations and their dynamics. I grew from the problems and solutions found, but I could never solve all of the problems during my time with the project. I was able to get some of them on the right track, and my former colleagues told me a year after I left that the changeover was complete, except for one environment where it was no longer worthwhile.

Care

Bonsai need care. The basics are location, fertilizer, and water. In summer, I have to water most of them three times a day. My crabapple also needs to be watered four times in exceedingly hot summers. The white pine was a little more frugal. It got by with one or two waterings in the same heat. However, it doesn’t tolerate overwatering very well.

Especially in the spring, I have to constantly watch my little trees’ growth. Which branches do I want to encourage and let grow thicker? Which upper branches do I have to prune and completely remove so that they don’t inhibit growth of those further down through hormone flow? Do I need to wire a branch so it doesn’t grow upwards?

Without this care, the bonsai will start to grow rampantly. The living work of art would quickly become outwardly indistinguishable from a tree we just picked up from the garden center. The roots would fill the pot and the plant is no longer able to get enough nutrients because the substrate is compacted by the roots. The bonsai would be damaged.

Software, like bonsai, needs structure. If we fail to make duplication in the code into a new structure, the same logic proliferates in many different places and needs to be adapted twice or three times if the system behavior changes. If code is always added without fitting into the structure and architecture, the codebase becomes unmanageable. Subsequent work takes longer and longer, as if you must first cut the rampant growth from a tree before you can start your actual work.

With bonsai and software, continuous care is the only way to get a proper, long-term viable result. Working on it only in case of emergencies or on-demand might be possible, but it leads to unnecessary stress and has a bad influence on the rest of your work, which needs to be interrupted because of this. Patience and time Bonsai are trees and they grow older than people. It takes years to get from raw material to primary and secondary structure of branches to a cultivated bonsai. In the Japanese bonsai tradition, they try to keep it in the same design from that point onwards. Newer ways of thinking in western bonsai schools change designs again after a few years, because the plant wants to keep growing.

Bonsai are cared for, developed, and often passed down in the family for decades, or sometimes centuries. They are highly prized heirlooms. The oldest known bonsai is more than 1,000 years old. A famous four hundred year old bonsai survived the atomic bombing of Hiroshima. A bonsai’s individual beauty also lies in its experiences, difficulties, and events it went through during its life. Some of these can be seen in scars in the wood, in the bark’s callus, or dead wood elements in its design. The aesthetic is not perfect abstract structures, but one of grown, imperfect roughness.

Working on software also takes patience and time. Features aren’t ready overnight. Often, it takes patient work and rework until its main functionality is ready. Then it goes to the exceptions and bug cases. The software’s scars are hacks, quick changes, and shortcuts we took due to time constraints. Many of these will persist during our time on the project. If we’re lucky, we can improve a few of them. Every change always has the implicit requirement that everything else should continue working. The software must be kept alive, like a tree, no matter what work we do on it.

What now?

Bonsai got me thinking about my work. Do I construct software according to an ideal image or do I help it grow in its direction? Do I let software grow in small, releasable steps and have flexibility for emergencies and plan changes, or do I choose the straightest, “fastest” path to the goal that only works under ideal conditions? It’s become more important to me to make software better instead of rewriting everything due to lack of perfection.

The mechanistic model I had previously for software now feels incomplete to me. It ignores many social, human aspects of software development. These are probably all basic insights for Agile and technical coaches, but I think they’ll also do us developers good. We often think of ourselves being primarily responsible for technology and overlook the fact that we live in a complex, socio-technical system. Disciplines like pairing and team programming often bring these social aspects to light in the team. It’s not the fault of pairing if people fight over who controls the keyboard. Instead, pairing reveals team dynamics and the needs of those involved. Address these needs as they come to light and the team will grow, become happier, and more productive than they could ever achieve with just new tools and frameworks. The system and developers grow better together than they would through pure code editing.

“You grow bonsai and bonsai grow you” is the sentence I would like to end this with. Bonsai has made me more aware of how much software gives me in my development.

Thank you

This article is the English version of “Software und Bonsai”. It was also published on devm.io. Thank you to Elisavet Vasileiadou and Sarah Schlothauer for the translation and their support with the English version.