The Distinction Between Technical Debt and Technical Obsolescence and the Significance of Knowing the Difference

An Opinion Piece and Article By Action ICT

You may have heard the terms technical debt and technical obsolescence being frequently used interchangeably, but what do these two terms mean and what is the difference between them? Knowing what each term refers to and how they differ can be vital when reducing technical frictions in product development. The essence of this article is to educate the reader on this critical topic.

What is technical debt?

Technical debt refers to what happens when development teams implement actions to speed up the delivery of a project or piece of functionality that must be refactored later on. In simple terms, this method prioritises speedy execution over quality code. This phrase is broadly utilised in the technology space.

A tool with consequences – debt repayment

When considering technical debt deeper, we can refer to it as a tool to help developers get ahead of the game. It intends to achieve rapid gains whilst facing the consequences in the long term.

Indeed, as the project matures, any code with technical debt can decrease agility. This code allows you to take shortcuts to achieve goals earlier. However, this results in an uglier cost, making the code harder to maintain. If you fail to align your software with how the market deals with and relates to your subject matter, you may encounter product and market dissonance. This works similarly to paying an incremental interest on loan repayments month on month; on one side, you understand the product you are building, and on the other hand, you have the code that reflects that understanding. At each stage of the process, you have a mirror. When refactoring in a staged mirror approach, you will not have a distorted image through the mirror of the application function. Thus, the current process keeps you going until a stumbling block is hit.

Strategic repayment: – Action  ICT Solution 

Analyzing point where technical debt has been borrowed (Developers/Managers Interview)

Use tools to reduce technical debt (Sonarcube etc)

Create //TODO [Debt Repayment] label in code

Plan Time to repay the debt (Accordingly future development and goals)

How to estimate the financial impact of a technical debt

As a reminder, Technical Debt is a metaphor that was used for the first time in 1992 by Ward Cunningham [W. Cunningham, “The WyCash portfolio management system”, ACM SIGPLAN OOPS Messenger, vol. 4(2), pp. 29–30, 1993. ].

To summarize this definition, let’s quote him:

• “Neglecting the design is like borrowing money
• Refactoring, it’s like paying off the principal debt
• Developing slower because of this debt is like paying interest on the loan.
• Every minute spent on not-quite-right code counts as interest on that debt.”

Click this link to see a Formulas and calculations illustration

Technical Debt Ratio (TDR):

Technical Debt Ratio = (Remediation Cost / Development Cost) x 100%

Development Cost: DC [hours]

Lines Of Code: LOC [lines]

Cost Per Line: CPL [hours]

Remediation Cost: RC [hours]

Technical Debt Ratio: TDR

So, referring back to the definition of the TDR, we can write:

TDR = ( RC / DC ) x 100%

Where:

DC = CPL x LOC

Let’s use the equation to calculate total TDR where the remediation time is 365.8 hours; lines of code is 26,398 lines; cost per line is 0.27 hours/line.

RC = 365.8 hours

LOC = 26,398 lines

CPL = 0.27 hours/line

Recall that DC = CPL x LOC

=> DC = 0.27 hours/line x 26,398 lines   DC = 7,125.83 hours

Therefore:

TDR = ( RC / DC ) x 100%  => TDR = ( 365.8 hours / 7,125.83 hours ) x 100%

TDR = 5.1%

The technical debt ratio for this example codebase is 5.1%.

High is the ratio higher will be the cost of maintaining the codebase.

Causes of technical debt

This problem is frequently triggered by company pressure to prioritise speed over sufficient code, a lack of attention to code quality, and insufficient information about users’ requirements.

What is technical obsolescence?

Technical obsolescence refers to when a specialised service or product is no longer required, even if it is still working. Obsolescence usually occurs when an innovative, new product has been generated or when upgrading a software framework is necessary, thereby replacing an older version. It’s good to have a planned check-up to be up to date. After all, being ready to expand your business and serve new clients with the latest technologies is attractive. However, there are approaches you can take when avoiding vulnerabilities and reducing the risk of obsolescence.

Attributes of technological obsolescence in particular types of assets

There are many different characteristics of obsolescence in specific assets:

• Replacement parts cannot be obtained in good time without placing a building and its occupants at unnecessary risk
• Complimentary tools are not available anymore
• The asset has come to the end of its life
• A project requires the implementation of modernised techniques

Causes of technical obsolescence

There are three major causes of technical obsolescence that are often caused by advancing technological developments and the high sophistication of user experience. However, this problem could also be a result of a lack of product and user foresight and a lack of implementation of periodic updates. Other causes are far less prevalent and have much lesser consequences; therefore we can ignore them for now.

The relevance of knowing the difference between technical debt and technical obsolescence

From both business and technical perspectives it is important to establish the difference between technical debt and technical obsolescence.

The best place to start is to clearly define both; as we have done earlier in this article – this hopefully will give you knowledge of how to tackle each problem correctly.

For example, technical debt can increase your development costs when not managed efficiently, allow a system to become more prone to cyberattacks, and reduce your customer base. Thus, avoiding these issues within your company is essential for long-term development and success.

To avoid technical debt, you need to compromise code quality only when necessary, remembering to refactor your code according to the strategy. If you have already compromised your code quality, you can do a few things to reduce the problem of technical debt. For example, you could measure the time needed to reduce the debt and create a planned pay-off period according to this. You could also set coding standards and implement the culture of automated tests and code reviews for the foreseeable future, as well as carry out a technical debt analysis to identify your current problems in the code.

As for technical obsolescence, you may end up with many useless parts or not have enough spare parts in stock. After identifying obsolescence, you can take a few steps to reduce it since rewriting obsolete code and introducing a new framework and new library may be tricky and time-consuming.

For example, you could anticipate the risks of obsolescence occurring in stock. You could set up an indicator of stock obsolescence based on your products’ lifespan as well as manufacturer announcements. With an efficient follow-up, it will become easier to anticipate the obsolescence of various parts, allowing you to adjust stock with operations such as destocking and promotions. For spare parts, you should identify which parts are critical to the overall functioning of your fleet, stocking these in sufficient quantities to avoid a lack of stock if a manufacturer fails to offer adequate support.

Furthermore, you should utilise training to reduce the risk of obsolescence. This means you need to share efficient practices in employee training sessions, allowing for the generalisation of optimal utilisation of operating systems.

Moreover, you need to be able to support obsolescence when it becomes inevitable. There’s no doubt that some equipment will become obsolete. In this situation, you can attempt repairs, with specialist spare part sites sometimes having stock. If you have no alternative but to get rid of the equipment, you could donate to specialised associations, ensuring that your spare parts are given a second life. An excellent technique to utilise is a phased upgrade approach, which will allow you to keep your business running smoothly.

The best solution to minimise any obsolescence risks is to consider as-a-service models. You could choose to rent equipment instead of buying it, ensuring that your equipment is constantly up to date and you don’t have to worry about long-term obsolescence.

Final thoughts

Hopefully, you now know the difference between these two technical terms. Whilst architectural constraint sometimes limits the structure of codes, it’s worth being aware of how each term can be affected by its code structure. Learning about technical debt and obsolescence can sometimes be challenging, but knowing their differences is crucial to enable you to tackle and prevent each of these problems in the long run.