Technical Debt is a broad sweeping term that comes out of the Finance industry. Its meaning and relevance are not fully understood by most who use it. I intend to talk about the use of the term “Technical Debt” and suggest we replace it with the term “Technical Risk”, as well as give some guidance on what is and isn’t Technical Risk.
Technical Debt was a term coined by Ward Cunningham, one of the Authors of The Agile Manifesto, while working in the finance industry to explain what was happening in the code to financial managers. He needed to explain explicit design decisions in a way that people in Finance could understand. So, he chose to describe the postponing of some aspects of design as a loan. This was an intentional desire to delay design decision until more was known. Therefore, the team took on some risk intentionally to capitalize on potential.
It’s about Risk
Ward was trying to get managers to understand the very real risk of losing money, increasing cost, and other bad things. The design of code can cost money in a couple of ways. First, it can, and does slow development time thereby increasing the cost of future features and bug fixes. Second, it can make code difficult to understand thereby increasing the chance that a change will result in a bug. Risk can be assessed, categorized, and handled.
Ward used the term as a metaphor. Like all metaphors, it can be useful but has its limits. Since Technical Debt is really talking about risk, I often use the term “Technical Risk” instead. This encourages a discussion on what the risk means on our system. It also allows us to approach it with systems we already know and are familiar with like standard Risk Assessment.
Lastly it is worth saying that no system is without risk. The question really is, is the level of risk acceptable within the system? Once we can answer this question, then we can make logical meaningful decisions around Technical Risk that fit our business plan for the software in question.
What is Technical Risk
Technical Risk being a code level risk means it exists within individual files of code and is about the structure of code within a file. This could be a portion of the code that few people understand, or a segment of code that is particularly difficult to change without effecting something else.
There are 3 causes of Technical Risk, each are valid and worth understanding as they aid in our assessment of risk.
There are times when release pressure or some unresolved decision leads a team to intentionally take on risk. This allows them to be heads down for a bit without worry of how the decisions they are making now will impact them in the future. The problem is longer the team waits to address this the harder it becomes to address. When assessing this type of risk, time is a major feature to reducing the risk.
Unintentional risk is caused by the team or someone on the team not knowing how to avoid making a risk embedding decision. Since code level risk assessment is seldomly taught, and no one can be aware of all things all the time, this is not a statement on the quality of the programmers. When assessing this kind of risk, the key feature is training.
Code Rot Risk
Code rot risk happens because decisions that we made a few months ago, despite being the best possible decisions, did not have the insight we have today. We learn and grow while our code largely stays stagnant. This is a good thing, but it does introduce risk when it comes time to change the code. Automated systems that alert us to breaking changes helps mitigate this kind of risk. Code coverage is a key feature to assessing this kind of risk.
My last point on Technical Risk is when using the term be aware of your audience. Talking about risk as debt might work well when talking to a business manager who understands finance. Talking about it just as risk might be well suited to other managers. However, neither are well suited for discussions between developers.
When talking to management at all levels within a company, I find using their familiar terminology while accurately conveying the information is best. That might be risk, debt, or other language. It is more important to accurately communicate the needed information then to hold to vague technical jargon.
I suggest developers do not use these terms when talking about the state of the codebase to each other. There are more accurate technical terms to use in all cases. The technical terms also give guidance on how to alleviate the risk they are seeing.
In all considerations of audience, the goal is to concisely convey the information needed to make decisions based from the current structure of the codebase. As such we need to choose our language and terms appropriately.
Technical Risk is about the risk that something will happen. If a bug is found, it is not technical risk anymore. A bug may be a business risk, but the technical risk comes in repairing that bug. Or in the risk of other undiscovered bugs existing in the code. Calling a bug Technical Risk or Debt confuses things. The term should be limited to talking about how the structure of code may lead to future loss of money.
Technical Risk is also not a critique of the skill of the programmer or quality of the code base. All code has risk. If we simply ask what an acceptable level of risk is, we can dispassionately plan to mitigate that risk. The moment we use it as a critique we lose the ability to approach it objectively and dispassionately. It is worth saying that using Technical Risk as a critique of the code also prevents mitigations that do not result in changing the code.