Proximate and Ultimate Causes of Technical Debt

A lot of people have tried to address the technical debt problem, with varying degrees of success. In previous articles, I have explored reasons why, including the fact that technical debt is misunderstood, plus we try to deal with technical debt at the wrong place.

In this article, I’m going to look at another reason – when we look at technical debt, we tend to look at proximate causes, rather than ultimate causes. The problem is, if we stop our search at proximate causes, we never address the ultimate problem. Indeed, by addressing proximate causes, we can even make the problem worse. Our tendency to confuse proximate causes and ultimate causes is partly due to our blindness to half of the technical debt life-cycle, a topic I covered in an earlier post.

In Taming Your Dragon I explore proximate and ultimate causes, plus seven other reasons why technical debt has proven so resistant to our attempts to solve it.

When we try to truly understand why any event happens, we need to distinguish between the immediate, proximate cause of that event and its ultimate cause.

For example, if we are trying to understand why someone has died, we may learn that they died because their heart stopped. This is not particularly enlightening. Indeed, cessation of heartbeat could be considered a definition of death.

We may then learn that their heart stopped because of a traumatic loss of blood. This gets us closer to an ultimate cause, but still leaves us with the question – why did they suffer that traumatic blood loss?

Perhaps they had a traffic accident. If we dig further, we may learn that a driver was distracted, or perhaps had been drinking, which led to the traffic accident.

In the example of a road traffic victim, there is a clear causal chain, so we are unlikely to conflate the proximate cause of heart stoppage with the ultimate cause of drink-driving.

However, in the case of technical debt that is incurred through software development, the causal chain leading to that technical debt is often unclear, leading us to conflate proximate causes with ultimate causes.

For example, the technical debt may have occurred because the developer elected to implement the code in a certain way. However, this is merely the proximate cause. If we stop here, then we learn little that can help us reduce our technical debt.

Instead, we must dig deeper and ask why the developer elected to implement the code in this way. We then need to ask ‘Why?’ to that response, then repeat this until we reach the ultimate cause. This is the heart of the five whys technique, commonly used in root cause analysis.

Was it because the developer was unaware of the limitations of their chosen approach? If so, why was that? Alternately, were they unaware of planned future development that would be hampered by this implementation? If so, why were they unaware?

Perhaps, most likely, the developer was under significant schedule pressure, and this solution offered a way to quickly deal with this coding problem, then move onto the next pressing problem on their list. If so, your chain of subsequent questions will likely lead you in a very different direction from the one you originally anticipated.

In accident investigations, it was previously normal to stop the investigation at the proximate cause of an accident, which was usually identified as the unfortunate operator in charge at the time of the accident. This often suited the parties conducting the investigation – they had a cause, a person to blame (who was not themselves), and they could show they had conducted an investigation. This approach also allowed the organisation to avoid any painful self-examination.

The major downside was that the investigation was ineffectual, little was learned, and a repeat accident often ensued.

The accident investigation community has moved on from this na?ve approach, with the result that far more is learned from accidents, leading to significant safety improvements in many industries, especially in aviation and medicine.

Organisations trying to reduce their technical debt are frequently handicapped by focusing upon the proximate causes of that debt, whilst ignoring the ultimate causes. Some may even be unaware that ultimate causes exist.

This focus upon proximate causes occurs for similar reasons to those in the accident and safety investigations. Firstly, the causal chain to the proximate cause is clear and distinct, whereas ultimate causes are usually hidden and diffuse. Secondly, there is a desire to get to a clear-cut ending, which a proximate cause provides. Finally, identifying the code or an operator as the cause avoids any painful self-examination by the organisation.

Any organisation that wishes to be successful in dealing with technical debt must go beyond looking for the proximate causes of that debt, and instead it must seek out that debt’s ultimate causes.

#TechnicalDebt #TamingYourDragon #Apress