Zen Art of Software Development

Part I: Impermanence

Our daily life seems to be very permanent like our job, our relationships, the house or apartment we live in, the streets we pass by every day, day by day commuting, even our bodies and health. The busy pace of modern life makes us miss many things happening other than what we are focused on, like having “horse blinders”. This makes our perception of things to remain unchanged, even become more permanent. More than a perception: we want things to stay as they are (as we wish they are), we don’t want to step outside of our comfort zone. We don’t want to leave the cozy corner. We don’t want things to change. We grasp for things to be permanent and we don’t want to suffer …

Pale blue dot — wikipedia commons

The humankind is longing for stability and permanency while living on a beautiful piece of rock in the middle of the universe. A “pale blue dot” spinning around itself and moving around the sun, the sun moving around in milky way, and our galaxy the milky way moving through the universe. While we are sitting still, we move at 0.1% of the speed of light around the universe. Almost for sure, we will not be visiting the same point in space ever again in our lifetime.

We live in a body that is growing, aging day by day, our skin renewing itself daily, our stomach and our liver renewing their cells non-stop. It is said that all the atoms in our body are replaced within one year (turnover rate). Neuroscience proved the Neuroplasticity of the brain. The structure of our brain is changing just because of our thoughts.

The term “impermanence” in Buddhism states that “all physical, mental events and states come into being and dissolve”. There is a flux of change and there is neither a beginning nor an end but just a process of ever changing states. In this flux of change, we tend to mark some states as extraordinary moments such as birth, the new job, the new car and death. According to the Buddhist point of view, we suffer because we long for permanency where there is only impermanence. Realizing the impermanent nature and seeing it “as it is”, is one way to eliminate “unnecessary suffering” from our lives. For now, let us just stay with the phrase “eliminating unnecessary suffering” related to impermanence.

Evolution is a pure process of change. We define the term “natural selection” mostly with the wrong interpretation “survival of the strongest” but it is actually about “survival of the fittest”. With the word “fittest,” Darwin meant “better adapted for immediate, local environment”. We can see it as a strategy to adapt to ever changing states, to adapt to impermanence.

As a hands-on software architect, I worked on many projects from start to the end (sometimes the bitter end). In the beginning of my career, I had a definition of a software project in my mind: It started with well-defined requirements, continued with well-documented design, with clean coding including high test coverage, followed by a well-defined acceptance test with a customer who supposedly knew what they wanted. And the senior management followed and supported the vision and strategy all the way without ever changing priorities. And we lived happily ever after. Having a human intellect, I realized after first couple of projects that there was something wrong with my dream. Almost none of my expectations came true. We consistently failed in different projects in different parts of my imaginary project execution. We suffered as whole teams. I include customers, senior management, developers, testers, support, sales, … every one of them if I may say “team” now, but it was not always that inclusive. The default reaction was blaming others collectively. Sometimes, it was sales people’s fault because they sold whatever they could sell without considering the limitations of the product. Sometimes, it was the fault of the support team because they did not educate “themselves” sufficiently to support the product in a better way. Sometimes, it was the customer’s fault because they didn’t know what they wanted in the first place. And the list went on. For a long time, I was caught in this vicious cycle — samsara. The terms like “Evolutionary architecture and emergent design” resonated but I couldn’t grasp its totality at that time. There was an intuition about the cause of this suffering but nothing explicit came out. Later, I tried to apply methods of agile software development and I was part of teams having the intention to apply methods like scrum. It was not perfect but it alleviated some suffering (meanwhile, let us repeat “It is a process not a perfect”). It got better over time by working with like-minded people who wanted to suffer less. But still we just used methods or tools labeled with the term “agile”.

The main shift came with time after I started to apply Buddhist practices in my personal life. There was a crack and the light came in (with “Anthem” by Leonard Cohen playing in the background). I slowly realised that we resisted the change in the project requirements, change in design; we resisted the change in existing code-base, change in priorities; we resisted uncertainty and we resisted collectively. This resistance caused suffering, rigidity, separation, and unproductivity. For myself, I had expectations like finalizing the design, closing and sealing it and finally starting to code some fun stuff. I had expectations like using that framework or this framework; I had expectations to reuse some existing stuff. However, because I couldn’t see it as a process of ever changing states, I suffered when these expectations were unfulfilled. The agile tools caused a temporary relief if and when used just as an instrument. But they couldn’t uproot the cause of suffering itself, namely the fear of change!

Buddha talked about not believing in doctrines blindly but to test them with our mind (common sense) and experience them (by practicing). In real life, it may take months — possibly years — to test the effects of doing some Buddhist practice such as Mindfulness but as software developers we have the luxury to test our ideas, assumptions and design as early as possible and rely on data. We can respond skilfully based on actual data instead of reacting based on fear of a potential change. Unfortunately, that is something we forget very easily and let ourselves to the attraction of assumptions. In every step of a project, there may be assumptions we may test instead of just assuming and wasting hours on discussing things based on these assumptions. At this point, I would like to refer to “Lean Startup” and “Lean Software Development” for further reading.

This realization only emerged after I started to see practice and life are indeed inseparable. If you practice meditation, there should be an extension of that in your daily life. And your daily life includes your job as well. And I realised that the value of integrity is very important to me. And it is all inclusive; meditation, daily life and business. Nowadays, I practice seeing impermanence in action and try to observe the fear or anxiety arising, breath and call it by its true name. Seeing things as they are is a way of eliminating “unnecessary suffering”.

The following is a selection of software architecture and development strategies that I benefited from along the way, trying to keep up with change:

Such strategies are much more clear, much more meaningful after reflecting on impermanence. They increase our adaptation capabilities, so that we can keep up well with the impermanent nature of things, software development projects in our case. They are also good to “sharpen the saw”. But still they are not the only and final solutions, mindfulness of our feelings and reaction are also essential.

In Buddhism, “you start from where you are”. This story is about where I have started. The process called “me” continues non-stop, still rounding the cycles of samsara. And maybe it will have a further manifestation in the form of a writing.

Additional References