What Is Technical Debt: A Guide

A common term in the software community is “technical debt.” Referring to actions the development team takes that require repayment in time and effort in the future, technical debt—also known as design debt or code debt—is specific to the technology space. 

For current and aspiring software developers, it’s vital to understand what technical debt is and its consequences. 

Continue reading to explore various types of technical debt and discover strategies to minimize their impact. 

What is technical debt?

Technical debt refers to development teams' actions to start a project that will later need refactoring. Credited to software developer Ward Cunningham, one of the many authors of the Agile Manifesto, the term technical debt mirrors financial debt. 

In a video on his YouTube channel, Cunningham described communicating the cost of rushing software before it is ready to his boss using “the debt metaphor.” He likened it to paying interest on a loan: "With borrowed money, you can do something sooner than you might otherwise. But then, until you pay back that money, you'll be paying interest.” Regarding technical debt, the interest is “refactoring the program to reflect your experience as you acquired it” [1].

In other words, technical debt helps developers get ahead, but that progress comes at a cost. You can achieve rapid gains, but you’ll likely have to go back in and make fixes later on.

Consider it this way: With technical debt, you take shortcuts when creating code. Doing so builds long-term consequences that can decrease the code’s agility as the project matures.

Technical debt consequences

Whether intentional or unintentional, tech debt has several consequences. The code, product, team, and business can all feel impacts, such as:

• Coding complexity and bugs can increase while coding capability decreases.

• Product delivery could benefit, but the functionality can decrease, and risks rise. Plus, issues could lead to more recovery time later.

• Integration of work across teams grows more difficult because of the need to rework.

Intentional vs. unintentional technical debt

You may encounter different views of technical debt. Some say it’s always intentional. Technical debt refers to decisions based on an actual project to benefit the existing timeline or objectives. So, for example, developers might make a conscious choice to prioritize expediency over developing robust code.

Some say unintentional tech debt is a misnomer and another way of describing lazy coding. However, other research accepts that development teams can accrue unintentional debt by prioritizing “client value and project constraints, such as delivery deadlines, over more technical implementation and design considerations” [2].

Martin Fowler developed the Technical Debt Quadrant to break down unintentional versus intentional technical debt. This model categorizes debt into four categories, considering whether the debt is deliberate or inadvertent, as well as prudent or reckless. In this model, tech debt could be:

• Reckless & deliberate (e.g., “We don’t have time for design.”)

• Reckless & inadvertent (e.g., “What’s layering?”)

• Prudent & deliberate (e.g., “We must ship now and deal with the consequences.”)

• Prudent & inadvertent (e.g., “Now we know how we should have done it.”)

You might also see technical debt described as active or passive, as opposed to intentional and unintentional.

Types of technical debt

You can also classify types of technical debt by focusing on their nature. For example, the Software Engineering Institute identifies 13 types of technical debt. This section outlines some of those types of tech debt and what they entail.

Architecture debt

Architecture debt refers to choices that increase complexity or damage stability to make software architecture more flexible or adaptable. Solid architecture works seamlessly, and when core functions depend on one another excessively to the detriment of maintenance, you could have architecture debt. 

Code debt

Code debt creates difficulties in the source code, which you can accrue intentionally or unintentionally. When you know code debt in advance, you can explicitly note what needs attention in the future. 

Defect debt

Defect debt refers to postponing fixing a defect or bug. That decision can offer short-term gains by cutting time, but long-term consequences can occur as those defects or bugs continue.  

Design debt 

Design debt, also found in the source code, refers to decisions that undermine common principles of object-oriented design. It could accrue if changes are made without properly refactoring existing code.

Documentation debt

When developers fail to document their changes or processes, documentation debt accrues. Poor quality documentation or an absence of documentation may not initially pose problems, but it can make upgrades and maintenance more difficult to navigate without past context in the future.

Infrastructure debt

You can have infrastructure debt when your information systems don’t meet standards or requirements. It might occur when you don’t continuously integrate or update old and new systems.

People debt

Insufficient training, poor hiring practices, or a lack of retention can lead to people's debt. The development team could suffer from knowledge loss and internal conflicts in this case.

Requirements debt

Picking and choosing which requirements you’ll meet—instead of meeting them all—leads to requirements debt. Your decisions around how and when you meet requirements can also accrue this debt.

Data debt

Data that needs to be correctly formatted or is redundant, inaccurate, or missing results in data debt. This technical debt can hinder the maintainability of the entire information system.

Test debt

Test debt is a lack of testing, poorly executed, or inappropriate testing. A sign you may have test debt is if you need to manually perform tests you previously automated. 

How to reduce technical debt

Tech debt, like financial debt, isn’t categorically bad. A problem, though, is that technical debt is less visible. For example, if you're a member of the business staff working on a project, you may not fully understand the technical jargon used by the software team, including, but not limited to, "technical debt." So, how do you tackle and reduce technical debt in this context? 

First, you need to lead with transparency about the debt load. You can better manage the load and resolve gaps by tracking and communicating tech debt. Strategies to address technical debt include the following:

• Put procedures in place to identify tech debt during coding.

• Establish a tech debt tracking system that reports your debt, the time it will take to pay off, and the refactoring process.

• Use automation to respond to technical debt, monitor the progress, and act before issues escalate. 

• Track this debt as part of your Scrum product backlog and prioritize the debt along with the rest when refining your sprints.

• Motivate development teams to pay down debt before it causes bigger issues. Unaddressed tech debt may require more time to resolve, even necessitating starting over from scratch.

Next steps

During a software product launch, it may only sometimes be possible to prevent debt. Understanding technical debt and its costs can help you in a software developer career. You can try the IBM DevOps and Software Engineering Professional Certificate on Coursera to gain more skills. This beginner-level course can expose you to many essential skills, requiring 10 hours a week over three months.