Technical Debt is one of the more commonly found terms in the software development field, and can be used to describe the issue with using faster or ‘quick fix’ solutions in code. However, one of the less commonly discussed terms is Technical Risk.
In this blog we will be looking at Technical Debt and Technical Risk, and whether the short term pay off from using them, is worth the potential long term issues.
Technical Debt
Technical Debt, also referred to as Code Debt, is the implied cost for choosing an easy or limited solution at the start of the coding process, instead of using a better solution that may take longer. As with all debt, Technical Debt often accumulates with time, which makes it progressively harder to implement changes at a later date.
According to Martin Fowler’s blog titled “Technical Debt Quadrant”, there are two main forms of Technical Debt incurred, as shown below: Reckless debt and Prudent debt.
Both of these have two main cases where they are found. Firstly, where the debt incurred is deliberate, often as a result of constraints placed on the team or deliberately choosing a different method. And secondly, inadvertent, as a result of ignorance or realizing in hindsight that there may have been a better solution. Each of these forms of debt comes with inherent Technical Risk.
Technical Risk
This is the potential impact of the Debt incurred as a result of the differences between the actual design, and the optimal design solution. The extent of this impact can be measured according to these three points:
- the objective that a person or an organization wants to achieve,
- the person or organization that the risk emerges for, and
- their decisions or solutions to change the impact of risk.
In the first point, the organization runs the risk of having the incurred debt jeopardize their end product. This takes the form of having the project scalability or functionality risk being compromised as a result of sloppy code, or corners being cut.
In the second point, the debt will have an impact on the individual or organization, as incurred debt can impact the image of the organization. This is a difficult risk to accurately assess, because the true extent of it will often only be understood or encountered when the project is reworked or the product crashes.
The other side to this concept is how the risk may be handled within the organization, some people may disagree over the protocol. This may lead them making contradictory decisions.
The final point is in the way that the Technical Debt is preemptively handled. Code Debt, though sometimes not intentional, is more often than not a part of the code we write. In order to reduce the risk that comes with this, it is important to prepare in advance.
Have measures been put into place to facilitate the processing of the Code Debt once the initial process or time has passed for which the shortcuts were needed?
At the end of the day, debt is not necessarily a bad thing. In the case of Code Debt, it can be good in that it enables a project to be finished, or allows a shortcut to be taken to save time. However, in the real world, debt is a known quantity. You know how much debt you have, you know the rate at which it’s increasing, and you know what it will take to pay it back. Occasionally you may incur more than you can bear, but it is always a very real and present concept.
In the coding sense, this is not always the case. As the old saying goes, “out of sight, out of mind”. This is the danger with Technical Debt. Once you have pushed that portion of the project, you may have a tendency to forget about it, until it is too late. A project will often work fine with some debt, but with time it will build until there is a failure, and often by this point it is too late. That is no longer Debt, that is Risk.
Conclusion
As with all things, there is no definite right or wrong, there is a best practice, but each individual will still try to do things their own way. It is good to know the difference between the Risk and Debt, and to be able to determine at which point you are taking on too much Debt and incurring risk. Debt will never be a completely good thing, but it has its place in the software development space.
