Intro

This is a pour out of a shower thought, more than a post it may end being a stub on the topic.

Is the art restoration process somehow similar to DevOps and the software development life-cycle, or am I going crazy?. After almost a year reading about DevOps and best practices on software development I was watching, more like listening, to Baumgartner Restoration Julian Baumgartner (we will call him by his name in this post) and found that almost everything he was saying about the way he works in order to restore a fine art painting can be applied to software development, when working on to a legacy monolith or even when working in a brand new project.

Cause no harm

When Julian is working restoring the painting he makes sure that all of the original work is preserved, Julian ensures that everything he does is isolated and doesn't alter or damages the original painting. If we try to translate this into software development the idea of orthogonality, and decoupling pops into my mind.

When we work onto a software codebase we should ensure that the feature we are adding in does not collide or interfere with others, that if we are fixing a bug the fix does not cause other bugs in a domino effect, this means that we should write decoupled code that works in synergy but allow us to isolate faults and bugs. We should not be causing more damage when putting out a fire.

Make it lean

Before any work of restoration can start Julian cleans the grime, dust and impurities from the painting. We as developers must ensure that the code we write is functional and complies to the specs, but we should also clean the codebase whenever we have the chance, or notice it has started to accumulate impurities or bad practices (technical debt, software rot, or however you like to call it). As Julian we must clean our codebase from technical debt before starting to work in the bugfixes or features.

Everything should be easy to change, reversible.

This is the topic that encouraged me to make this post, the great "aha moment" when watching the restoration process. Whenever Julian started to work on adding new pigment to the painting, isolating his works, protecting the painting and the restoration he has made; Julian takes a great deal into making emphasis that everything he has done is reversible. Everything done by him is easy to change.

Again we as developers should have this in our mindset, our code should be reversible, our code should be easy to change. It may sound sad to some, but the necessities from the business keep changing, what pleases the client one day may not please them the next week, the requirements can change, the third party software we use can change the way it behaves.

Given all that our software should be prepared to change, should be ready to discard something that we wrote in order to favour a new requirement. As Julian said: Some restorer in the future may think I did a bad job, or think that something can be improved and they should be able to easily change it, that's why every material in restoration should be reversible (im paraphrasing here, my memory is not that good and tbh i don't remember in which video he says it but this is the main idea).

In software development is the same, some future developer that is charged to maintain the code we wrote may find that there is a better way to do something or that, in the code we wrote, we overlooked something and that now is critical to add it to the codebase, and they should be able to change it with ease. Our code should be always easy to change, decoupled, independent and reversible.

Final notes

As I said this is more of a shower thought poured into a post. I would love to know your opinion and also you should really check out Julian's youtube channel is excellent to have him as a background when concentrating, specially his asmr videos (scrapping & more scrapping).

Disclaimer: I'm not affiliated or endorsed by Baumgartner restoration, I just though the concepts he talked about may be applicable in our discipline.