What is Technical Debt? Examples, Prevention & Best Practices

What is technical debt?

Technical debt is the consequence of putting speedy delivery ahead of optimal code quality. Technical debt happens when software development teams choose quick fixes over long-term solutions.

The debt metaphor is appropriate. When one assumes a debt, it’s often because financial resources are needed on a short-term basis. However, this creates additional costs down the line when that debt must be repaid.

“Technical debt happens when teams put speedy delivery ahead of quality.”

Technical debt works in a similar way, trading expediency for additional work down the line.

If the code isn’t eventually revisited and fixed, it can become a problem, just as interest and penalties can accrue if loan payments aren’t made.

Technical debt is not necessarily a problem. However, it can become one if the product is poorly optimized or has dysfunctional code.

Examples of technical debt

A classic example of technical debt is the Year 2000 (Y2K) problem.

Many software developers in the 1960s and 1970s chose to save precious memory by storing dates as two digits. So “73” instead of “1973.”

The practice continued for years, even as memory prices declined. Many of those programs became embedded into the operational business and stayed in use far longer than expected.

As the year 2000 approached, thousands of businesses and government agencies realized that date calculations would fail at a massive scale. This led to a frenzied clean-up effort that is estimated to have cost $100 billion.

$100 billion The cost of addressing the Y2K problem.

But technical debt isn’t limited to software. For example, a best practice in cybersecurity is to grant file permissions to roles within the organization rather than to individuals.

Suppose an administrative assistant gets approval for temporary access to sensitive documents they wouldn’t ordinarily be authorized to see. If the IT organization grants the exception and fails to revoke it later, it has given permanent access to sensitive documents. The account could eventually become compromised and present a vulnerability.

What are the downfalls of technical debt?

If short-term fixes are refactored quickly and developers know how to handle technical debt, there is little downside. There may even be benefits, as it can enable a business to respond quickly to opportunities or problems.

The risk grows when debts are layered on top of each other.

Quick fixes may be poorly documented or not documented at all. And when the people who performed the quick fixes leave, the company may have no one who knows how the code is supposed to work—or even that the quick fixes exist.

Enhancements or changes can create unintended conflicts that cause programs to fail or run slowly. Innovation slows as organizations fail to make improvements out of fear that change will break the application.

What are the different types of technical debt?

The two major categories of technical debt are intentional and unintentional.

Steve McConnell, CEO of the developer training firm Construx, defines intentional technical debt as that which is taken on consciously and strategically.

He defines unintentional technical debt as “the non-strategic result of doing a poor job.”

In 2014, a group of academics developed a taxonomy that comprises 13 distinct types of technical debt:

• Architecture debt
• Build debt
• Code debt
• Defect debt
• Design debt
• Documentation debt
• Infrastructure debt
• People debt
• Process debt
• Requirement debt
• Service debt
• Test automation debt
• Test debt

This classification is useful because it covers all areas where short-term thinking can create long-term problems.

How does technical debt happen?

Here are a few ways some types of technical debt can happen.

Intentional technical debt

Intentional technical debt is a conscious decision. It should be documented and scheduled for refactoring.

For example: A regional sales manager is under a deadline to generate a report that their platform can’t create. The manager starts using an open-source report writer to meet the deadline. That’s technical debt.

But if the development team spends resources to remove the open-source report writer and modify the master reporting system, that is intentional technical debt.

Unintentional technical debt

Unintentional technical debt is when changes are made out of expediency and without plans to refactor the code.

It can also result from poor design decisions caused by a lack of knowledge or failure to follow development standards. Unintentional technical debt in the realm of testing occurs when:

• Test suites are incomplete
• Testing is truncated
• Testing is skipped for the sake of convenience

Documentation debt

Documentation debt is common and happens when developers are too rushed to document their code thoroughly.

This can become a problem in the long term if a person leaves the company and doesn’t leave instructions to understand their code. Documentation debt was a major contributor to the Y2K problem.

Infrastructure debt

Infrastructure debt occurs when applications are built to rely on certain components, such as databases and file systems. The application might not work if these dependencies aren’t documented and the company migrates to a new infrastructure.

What are the warning signs of technical debt?

The warning signs of technical debt are:

• Projects getting bogged down because developers lack insight into the codebase
• Bugs that are difficult to fix due to complexity or lack of documentation
• Bug fixes that create new bugs or steady performance degradation

How to manage and prevent technical debt

Knowing how to handle technical debt starts with sound development practices. In a DevOps environment, that includes both shift-left and shift-right testing.

• Shift-left testing moves the testing process earlier in and throughout the development cycle. This is so problems are anticipated and solved before they’re embedded in production.
• Shift-right testing seeks feedback after applications have moved into production. This way, bugs are detected early and fixed before the software is in widespread use.

These create guardrails that prevent problems from growing out of proportion.

The workarounds that create technical debt are unavoidable and often necessary. It’s important, however, that developers document them, including the reasons why hacks were put in place and instructions for fixing them.

Regular audits of existing code can also allow team members to review each other’s work and spot documentation gaps or irregularities.

What are the best practices?

As organizations adopt DevOps techniques, they should clarify what is technical debt and apply agile tactics to manage it. This may include implementing:

• Shift-right and shift-left testing
• A/B and canary testing techniques to spot problems before they get out of hand

Peer code reviews allow fresh eyes to examine developers’ work. Developers should work with a consistent and limited set of tools and languages and have a checklist of tasks that must be completed at each stage.

An effective DevOps organization gives developers the freedom to choose how they build their creations. And it also provides guardrails to ensure they don’t spin out of control.

What tools can prevent technical debt?

The practices outlined above are a good start. Additional benefits can be realized by:

• Using automated testing to run multiple debugging cycles on every code change whenever there is a module change
• Establishing sound code structure procedures, including mandatory documentation to protect against workarounds
• Using project management tools to enable teams to see the status of everyone’s work
• Having programmers work in teams of two to enable them to understand each other’s decisions

Today, most software is written with low-code and no-code tools. These are self-documenting, with flowcharts and drag-and-drop techniques enabling a visual representation of logic and desired outcomes to be presented.

By applying these tools to professional software development, you can benefit from self-documenting features. Development managers should encourage teams to see low-code/no-code as a productivity enhancement, rather than a replacement for their elegant creations