Wabi Sabi Software Engineering

What does a well-known Japanese aesthetic have to do with software engineering? Well, let’s first start with the three tenets of Wabi-Sabi.

Nothing is perfect.
Nothing stays the same.
Nothing is forever.

Any seriously experienced software engineer will read these and think, “Hehe, of course.” Those of you who know this already, you can stop reading. But keep reading, please. Thank you. Let’s break down each tenet.

Nothing is Perfect.

Not only is perfection impossible to achieve, but the quest for perfection is unending. It is never completed. The Japanese interpretation of this is to find the beauty in imperfections. Repairing a broken plate with gold adds a beautiful asymmetrical design created by nature and how the plate broke. Finding imperfections is an opportunity to add beauty while repairing an object in the natural process of aging.

The quest for perfection can affect our craft, leading to long release times, analysis paralysis, over-refactoring, and delayed pull requests from unending comments.

I have personally both been affected by and have caused these issues. I have spent days on code that was just fine as it was. It was working, it did not have any bugs, and it was technically ready to deploy. But I knew there was a better way, with fewer lines of code. Some more perfect way that was more elegant. Ugh, elegant. A synonym for perfect. There will always be a better way to do something. That means as soon as you improve something, guess what? There will always be a better way to do something.

If the code works, ship it. If something pops up (a bug, a scaling issue, etc.), take the opportunity to fix it. There is beauty in that. Striving for improvement over time is possible and teaches us along the way. Making something perfect is just not attainable.

Nothing Stays the Same.

You know what gets better with age? Just about everything. People get wiser. Whiskey develops flavor and gets smoother. Songs get more memories attached to them. Furniture wears and gets more comfortable. Time’s effect on things can be a benefit.

To speak more like an engineer, code is ephemeral. Just because it’s pushed to a repository and deployed, I can guarantee you it’s not finished. As covered in the last section, nothing is perfect, you will find a way to improve it later. Changing this code is often seen as a failure during the first attempt. Rest assured, it is not. At the time it was completed, it was the answer. Sometimes the question changes. Whether it’s an unseen edge case that causes a bug or some lack of performance that was an issue under lower traffic in the past, the code was not unsuccessful when it was written.

Stuff changes over time, and improving code to consider these changes improves code. It is not a statement on the code (or the person who wrote it) when it is written. This makes the whole application better with age.

Nothing is Forever.

Many old things have lasted for thousands of years. There are even museums that display these items. But the more you zoom out on the timeline, the more things disappear. Zoom out a thousand years, and most man-made structures almost all disappear (even almost all those crazy old pubs in England). In technology, you don’t have to zoom out that much.

The static HTML website with a Perl-based CGI-BIN-based webform I made over 25 years ago is no longer around. Even the Space Jam website has been replaced. All the ASP sites that used Visual Basic client-side via HTAs. Those are gone. The new and shiny languages and frameworks are not forever. There will always be better tools that will replace old stuff. Today’s hotness will be tomorrow’s CGI-BIN.

Sometimes you will spend time building something, and no one will use it, just to be removed to avoid confusing the customers. This never feels good. But it is the stuff you learned from building it, the Customer’s reason for not engaging with it, and the benefit from removing it will teach you more than never having built it. You may not hit 100% of the shots you take, but you will miss 100% of the shots you don’t take.

Realizing that everything we build is ephemeral (whether weeks or years) makes the end of stuff much easier to stomach. Even if you think you are on a “death march,” there are always two outcomes. You could be wrong, and the result is not a failure. Hurray, Success. Another possibility is that it ends up being a failure. Hurray, you were right! Maybe next time, there will be something to help avoid another “death march.”

Wabsi Sabi for Code

So, thinking of the wabi sabi tenets in the context of writing code, let’s rephrase them:

Perfect code is unattainable. Ship functional code.
You or someone else will always rewrite the code you ship, and it will be better.
None of the code you write and ship will be around after a given enough time.

As I wrote each of these, I fought the urge to add, “…so get over it.” And I think everyone who writes code should… get over it and get on with their job. We write and ship code that serves whatever function that generates money that will pay our salary, so we can keep writing code that is not perfect, that will be rewritten, and eventually be erased.