What Is Technical Debt?

Technical debt refers to the buildup of extra work and costs when software developers take shortcuts. Despite the connotations of ‘debt,’ technical debt isn’t always a drawback for development initiatives, and can even be leveraged as a strategic tool to meet product goals.

Technical debt is a common occurrence in software engineering, often presenting itself when teams need to meet tight project deadlines or fulfill fast-changing product needs.

What Is Technical Debt?

Technical debt, also known as tech debt or code debt, describes the buildup of software work from using coding or development shortcuts instead of long-term, thorough solutions. Some of these shortcuts can include using poorly written code, using outdated software frameworks and libraries as well as not properly testing or documenting new code.

Over time, code solutions meant for temporary fixes can require fixes themselves, causing roadblocks for when a codebase needs to be updated, scaled or maintained. “There is no ‘one aha moment’ when a team realizes they have accrued this debt,” Anupam Singh, vice president of engineering at Roblox, told Built In. “Instead, it’s a trickle of incidents and issues related to ballooning cost and laggy performance.”

The phrase ‘technical debt’ was coined by software developer and Agile Manifesto co-author Ward Cunningham in 1992. Cunningham originally equated the idea of technical debt to that of financial debt, where technical ‘interest’ — the delivery and effect of suboptimal code — continually adds up if not properly addressed, and will eventually have to be ‘paid back’ through code refactoring.

Technical debt frequently “represents a strategic trade-off: opting for quicker achievement of immediate goals at the cost of future efforts to pay down the debt,” TJ Andrews, engineering manager at Bubble, told Built In.

Is Technical Debt Bad?

Technical debt can present itself as a bad or good occurrence depending on the company and a software team’s goals.

In some cases, technical debt is viewed as solely a developmental setback, as it may lead to reduced product performance, scalability difficulties and increased occurrences of software errors and bugs. Unintentional technical debt in particular, where a team isn’t aware of shipping inefficient code, can result in unchecked software decay and an increased workload when adding to existing infrastructure.

Some see technical debt as an inevitability when working with software, and just another element to factor into the development process. To deliver new features on time or use solutions that fit within development budgets, technical debt can be thought of as a tool to balance these product priorities.

“It’s impossible to not have tech debt, because if you didn’t have it you would pretty much never deliver anything.”

“I think it’s impossible to not have tech debt, because if you didn’t have it you would pretty much never deliver anything,” Kyle Hanson, technical founder of GetDynasty and former software architect at Carta, told Built In. “You can’t really think of it as a bad thing because it’s something you’re kind of forced to make a decision on whether you acknowledge it or not.”

Sometimes, technical debt can even be a positive sign that a business is growing. For example, if a platform’s user base is increasing and requires its infrastructure to expand to be able to support this number, technical debt will likely arise.

“Technical debt accrued due to increased usage is not a bad thing,” Singh said. “Think about debt as an increased tax liability; this is a sign of higher income, which is good news.”

What Causes Technical Debt?

Technical debt can be caused by a variety of factors throughout a software product’s development, both deliberately or inadvertently.
 

Budget Constraints

Developing code that yields the greatest benefits for a product may not fit within the budget or be seen as a worthwhile investment. Robust code solutions, especially those that involve building an entirely new system from scratch, often require more money and expertise to implement — without a guaranteed payoff. As a result, teams may opt to utilize fast, cheaper code solutions for existing codebases to save on expenses.

Claus Moberg, vice president of engineering at Roblox, emphasizes budgeting as one reason technical debt presents itself: “[Say] we built this thing the right way a long time ago, and it used to be best in class, but migrating off of it and onto the new industry standard is really expensive, risky, or time consuming, so we haven’t done it yet.”

Time Constraints

Tight deadlines play a role in contributing to technical debt, as teams may look for the quickest solution to be able to ship a product or new features to market on time. Though this means getting value to customers faster, it also means having more product deficiencies to make up for later on. “Here, you are knowingly shipping bad code,” Moberg explained.

Lack of Knowledge or Experience

Due to improper training or a lack of development experience, teams may not have the proper knowledge to create optimal code solutions for the long-term. This can lead to a surplus of unintentional technical debt, as inexperienced software engineers may not be even aware of or know how to identify detrimental code.

Lack of Sufficient Software Testing 

Software testing allows a team to uncover errors in a codebase and ensure a product is performing as expected before releasing it to customers. Without this testing, teams could easily miss bugs that affect the functionality of a product. This would require additional updates or patches to be released after a product has already launched, meaning additional technical debt to handle.

Related ReadingHow to Reduce Technical Debt and Bolster Your Cybersecurity

Types of Technical Debt

Technical debt is categorized as intentional or unintentional, with subcategories of awareness for each — overall known as the technical debt quadrant. This quadrant, created by software developer Martin Fowler, helps highlight the ‘why’ behind technical debt occurring, as well as identifies whether accrued technical debt may be considered as ‘good debt’ or ‘bad debt.’

1. Intentional Technical Debt

Intentional technical debt is any technical debt that is known and accrued on purpose. This type of debt is often used strategically in order to meet deadlines or remain within a project’s budget.

Deliberate and Reckless 

A team may know the best code to use, but opt for speedy delivery instead in order to get a product out the door as fast as possible. Deliberate and reckless technical debt can accrue when the stakes of a project are high, and only the most necessary code is used to complete it. It normally coincides with a conscious lack of product documentation and testing.

Deliberate and Prudent 

Deliberate and prudent technical debt is when a team purposely decides to ship a product quickly, but has a plan for sorting out consequences effectively later. Technical debt in this case is usually calculated and well-documented, so teams know what issues need to be addressed and how to build the software to make it easier to adjust in the future. This kind of debt can accrue when the stakes of a project, and the risks of using shortcuts in development, are generally low.

2. Unintentional Technical Debt 

Unintentional technical debt is any technical debt that is unknown or not intended to occur. This type of debt often results from a lack of knowledge or foresight into the most optimal solutions.

Inadvertent and Reckless

Attempting to use the best code solutions without having sufficient knowledge, experience or skills of how to do so can lead to inadvertent and reckless technical debt. This can look like a team implementing inefficient code or frameworks without being aware of more efficient alternatives. Inadvertent and reckless technical debt likely goes unnoticed and undocumented, making it more difficult to resolve later.

Inadvertent and Prudent 

Inadvertent and prudent technical debt occurs when a team believes that it used the best code possible while developing a product, but technical debt still arises. In this case, the team itself is knowledgeable about software practices, though unconsciously used less efficient solutions. This technical debt is typically unaccounted for at the start of development and not spotted until after a product has already been launched.

Examples of Technical Debt

Intentional Technical Debt Example

One example of intentional technical debt is a case where a system or platform must be scaled quickly to account for an influx of new users. Additional features on this system may need to be released fast, with eventual refactoring in mind, in order to meet customer needs and accommodate current traffic.

“The most significant instances of technical debt are when a system has to scale 10x but was designed for 1x,” according to Singh. “A prime example of this is analytic systems, which grow from 1PB to 100PBs with daily users going from 100 to 100K with a number of distinct workloads going from 10 to 100.”

Unintentional Technical Debt Example

An example of unintentional technical debt is a case where a software product was built by a team of inexperienced developers, and this product was not tested or reviewed properly before its launch. The team isn’t unaware of any shortcomings in the codebase and didn’t anticipate possible software bugs, leading to a need to address multiple errors after the product’s release.

While technical debt can be perceived as a disadvantage, it remains as a necessary component to maneuver when building software.

“If you’re on the search for the perfect product or code, you’re never actually going to be able to deliver the feature since there’s always going to be some deficiency,” Hanson said. Importantly, “as a [software] engineer, you need to make the choices of how you want to apply the resources and what matters the most in the short-term, and make decisions that don’t make it too hard in the future.”

Frequently Asked Questions