In several eastern philosophies exists the practice of giving in to “truths” and practicing to be encouraged to action by doing so. To live in between giving up to despair and to being in denial of them. Which is the continuation of where we left off in the previous chapter, on what constitutes non-beneficial actions. Using the practice and methodology of giving in, we’d try to define, extend and systemize The Beneficial Way Framework.
Eventualism
One of Buddhism’s cornerstones is impermanence, which is the opposite of everything is constant and everlasting. When it comes to software and software engineering, we do know from our own experience that applications are not constant. As we’ve seen in the previous series, a potential for change always exists due to evolutionary processes, caused by internal or external events beyond our control. Not to mention hardware failures, such as hard drives with bad sectors, corrupt memory and long power outages that prevent applications from running forever and ever. And not to mention the need to keep the business moving forward and meet our customer’s expectations.
And yet, when something does go wrong we are shocked to our bones and completely stressed about it. Even though we do know nothing lasts forever, we may be mentally attached to this misconception. This leads to mis-expectations, which leads to stress and blame by ourselves and others, engineers or otherwise. Stress and blame is exactly what we don’t need when we try to resolve the very same thing that went wrong.
Even worse, our binary thinking mind sees the opposite of everlasting as “not going to happen”.
Once again we know from our own experience it is not true. Failures do happen. If we’d be designing with a state of mind of “nothing wrong is ever going to happen” we’d be dooming ourselves to fail and even harder to recover. Such designs would be non-beneficial. Our binary thinking mind would then take charge and claim to do the opposite, to “design it to be everlasting!”. As nothing is everlasting, it would be non-beneficial as well.
In the previous chapter, we’ve learned of The Middle Way that helps us overcome our binary thinking mind. If we were to apply it the result would be:
The question still remains what is in between. We do know that failures would happen. As Change is the cause for Instability, the potential for it already exists within our own application. So it is only a matter of time until an event would occur that would cause a failure to happen. It eventually will happen.
And we would soon see that failure is not the only thing that eventually will happen.
From Nothing to Something
When we last spoke of The Beneficial Way we kept the question of “what is non-beneficial” open. Let’s try and answer that with Eventualism in mind.
First and foremost, we’d need to talk about the mental processes that lead us to do non-beneficial actions and by it define what these are. We’ll further explore the technical ramifications of these definitions in the next chapter.
One kind of non-beneficial action (the left edge) would be when we choose to do nothing by disregarding that something needs to be done, maybe even as minimal as raising a flag, reading the documentation or exploring for solutions. It could be the outcome of deciding to say nothing when we see something. It could be the outcome of saying to ourselves that now is not the time, which hastes evolutionary processes. It could be the outcome of our binary thinking mind saying “not going to happen”.
That’s where Eventulaims comes in. We’d need to instead tell ourselves “it will eventually happen”. It may sound counter productive. It may not sound beneficial to try and prevent the inevitable from happening. This is why Eventualism is not about us giving up because it is inevitable, it is us giving in to it. Accept the inevitable by trying to understand what needs to be done to postpone it for a significant period of time. And through it, understand what would happen when you don’t do that. That is the mental process that should push us away from nothing into something.
That’s easy to say but hard to do. Overcoming the mental obstacle of “not going to do anything” and “if it is inevitable I’m not going to do anything” is not an easy thing at all. It is hard to not give up when facing the inevitable. For some people a formulated way of decision making via effort and value would be appropriate. For myself, reading Uncle Bob’s Clean Coder made me understand what professionalism is in software engineering. For others, I’d like to offer a philosophical perspective that might help.
First, let’s ask ourselves “are we fatlists?”.
In philosophy “Fatalism is a family of related philosophical doctrines that stress the subjugation of all events or actions to fate or destiny, and is commonly associated with the consequent attitude of resignation in the face of future events which are thought to be inevitable.” (Wikipedia).
That is so depressing to be a fatalist (and non-beneficial!). I’m not saying that we are fatalist, but sometimes we do run into a fatalist state of mind. Who among us hasn’t at least thought to himself “this is too hard for me I’m giving up!”. That happens, but let us imagine a career of someone who is trapped in a fatalist state of mind, of someone who always gives up and does nothing. Whoever that poor suffering guy is, he’d be having a very short career. It is better not to be fatalistic, as we want our careers to be long ones.
Watch your Career
Speaking of careers, they are not only measured by what we do or where we have been, but also by what we leave behind. Through that aspect, there is something we can say to ourselves out of a sense of responsibility, or a sense of professionalism: “this will not happen on my watch and not on my successor’s watch”. The action would be to postpone it.
If it were to happen on our watch, it may look like we have acted unprofessionally. If it were to happen on our successors’ watch, then our successors might say we acted unprofessionally. “Oh yeah, it’s that guy’s fault for not taking care of this”. That’s not the kind of impression we’d like to leave behind. Saying “not on my watch” should push us away from doing nothing, to doing something beneficial. And instead of trying to prevent the inevitable, we’d just be pushing it into the future, so our professionalism will outlive us.
How far of a postponement would be beneficial? As a rule of thumb, 2 watches are 4-5 years. In this day and age where engineers are constantly replacing jobs, it’s a good estimation that a watch’s length is about 2 years.
If we wish to encourage it through culture and process, we can set the ground for it to happen. Do the following, either as a repeated mantra or an official workflow:
We’ve been given a specific coding task.
We see a beneficial change (one that makes this task’s coding or future tasks easier to do).
We can firmly estimate the effort up to half a day (4-5 hours).
We’re expected to do it without questions asked. We can put the task assigned on hold, get the beneficial change done and deployed, and only then get back to the task at hand.
If it is more than half a day to get done or half day has passed, I’ll question it and I’ll raise a flag to the team. Then and only then if it was decided to be non-beneficial we’ll let it go.
Erosion
Another kind of non-beneficial action (the right edge) would be to do something that should not be done. When we talked before about fatalism, we’ve stated that giving up is non-beneficial. But that is not 100% accurate.
Let’s say we have tasked ourselves with polishing an entire rock mountain – with a small sandpaper. We wish to create a beautiful monument that would last forever. We thought it would take us a year to do so. A year has gone by and the rock mountain still looks exactly the same. We should then be encouraging ourselves “We are not fatalists! We are never ever going to ever give up!”. 20 years have gone by and we still haven’t given up because we are not a fatalist and would never be one. 40 years have gone by and the mountain rock looks amazing. One day afterwards we died of exhaustion. No one else was crazy enough to continue our work so nature did what nature does and after 100 years of rain and erosion the rock mountain looks ugly again and nobody wants to see our monument. Polishing a rock mountain with sandpaper was not a beneficial idea.
40 years of waste occurred because we were not aware of rain and erosion. If we would have been aware of it, we would have known what it would eventually do to our rock mountain. If we would have known, we would have known not to task ourselves with it in the first place. We would never have reached the state of mind of “not giving up”. Some non-beneficial actions are born from unrealistic expectations or unattainable values. Which leads to incorrect planning, incorrect decision making and incorrect executions.
Instead we would have given in – and read on Wikipedia how Mount Rushmore was made and would have bought dynamite. That would have been a beneficial idea. That would be us accepting the inevitable and acting accordingly. That is neither giving up nor fatalism, but acceptance and giving into it. For both giving up and giving in we need to stop what we do. The difference lies in what we do after we stop. If we do nothing, we give up. If we find an alternative, we have given in. And by doing so it would lead us to find a beneficial alternative to get the task done.
But what is rain and erosion of software engineering? More on that in the next chapter.