Technical Debt: Definition, Examples, and Types

Properly managing technical debt can make the difference between a successful and a failed software project. On the other hand, ignoring or failing to identify tech debt can lead to higher development costs and lower business rewards. With so much at stake, understanding and dealing with technical debt should be a priority both for software developers and high-level decision-makers.

This article is a beginner's guide to technical debt. We explain what the term means, how it impacts software development projects, and how best to measure different types of tech debts at your organization. We also provide a range of effective practices that help keep technical debt in check.

Technical Debt Definition

Technical debt (also called tech debt, code debt, or simply TD) is the consequence of taking shortcuts during software development to achieve short-term results. A developer delays certain work to hit a deliverable or deadline but "gets into debt" that they must pay back with future reworks.

Tech debt typically occurs when a developer relies on easy-to-implement, sub-optimal coding or design solutions to rush production. The team then must return (at some point) to this product to add more functionality or revise the code. Here are some common reasons why companies make these tradeoffs between quality and speed:

• A strategic decision to test a market fit.
• Timeline or budget limitations.
• Poor software design choices.
• Inadequate coding skills.
• Flawed business decisions.

Technical debt functions like any other type of debt: you get convenience in the short run but must give payments plus interest later. Quick fixes and subpar solutions speed up software development, but addressing these issues in the future is expensive, constraining, and time-consuming. Some common symptoms of unaddressed tech debt are:

• Product bugs that lead to performance issues.
• Longer release cycles and time to market.
• Code quality concerns.
• Reduced team agility and productivity.
• Negative user experience.
• The higher total cost of ownership.
• Exploitable cybersecurity flaws.
• Difficulties with scaling and adopting new technologies.

Ward Cunningham, the author of Agile Manifesto, was the first to use the term technical debt to describe the impact of accruing tech issues. He also used the term "cruft" to describe the swept-under-the-rug code issues agile teams need to fix or "give back" to erase the technical debt.

Types of Technical Debt

While technical debt is always impactful, different types of debt are riskier than others. The debt you incur can be either deliberate or inadvertent:

• Deliberate technical debt (also called active debt) occurs when a company consciously delays the resolution of an issue to achieve a set goal (e.g., shipping an MVP to users to raise funds or get a proof-of-concept).
• Inadvertent technical debt (also called passive debt) happens by accident or due to carelessness, such as choosing the wrong platform or making coding errors.

Martin Fowler's Technical Debt Quadrant breaks down the types of tech debt further by defining two types of both deliberate and inadvertent debt:

We can also distinguish different types of tech debt based on what the team "owes", such as: 

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

Is Technical Debt Always Bad?

Technical debt is not inherently bad. Most development teams cannot avoid occasional tradeoffs between speed, cost, and quality. Technical debt only becomes a concern when you:

• Do not know about the debt.
• Ignore the accused debt.

Like a sound financial debt, a smart technical debt can have tremendous benefits in certain situations. Strategic incurring of debt can help:

• Deliver MVP solutions early.
• Confirm proof-of-concept.
• Determine product/market fit.
• Get speedy feedback.
• Meet customer needs quickly.

The impact technical debt has on a project depends on how the team deals with what they owe. Technical debt can be a valuable tool if a company:

• Makes a conscious decision to get into debt.
• Has the resources and knowledge to pay the debt off later.

Tech debt is also inevitable. The ever-evolving nature of software development means every product will require maintenance and re-building over time.

Technical Debt Examples

Below are three real-life examples of both deliberate and accidental technical debt.

Example 1: Prudent and deliberate technical debt

• Technical debt: Inflexible framework.
• Reason for the debt: Management sets a short deadline to reach the market quickly and get the "first movers" advantage.
• Debt description: Developers choose a framework that is fast to build on but has known flexibility issues.
• Debt payback: Refactoring the app to a more flexible framework.

In this example, the team uses a framework with known issues to achieve an early launch. Once the company meets the goal, developers go back to refactor components and remove code problems.

Example 2: Reckless and inadvertent technical debt

• Technical debt: Low-quality code.          
• Reason for the debt: Lack of coding experience.
• Debt description: Developers have poor coding skills, so the team writes low-quality code as they try to meet a tight deadline.
• Debt payback: Cleaning up and rewriting problematic code.

In this scenario, getting into technical debt is not a planned decision but a consequence of poor skill. The team ships a product with bugs that run up cloud costs and increase churn. The only way to pay the debt is to hire a more experienced developer to rework the code.

Example 3: Reckless and deliberate technical debt

• Technical debt: Wrong website platform.
• Reason for the debt: Developers prefer working with WordPress.
• Debt description: Developers choose to set up a high-traffic e-commerce website on WordPress because they prefer working with that CMS.
• Debt payback: Migrating the website to a new platform.

In this example, the team uses WordPress to build an ecommerce website. The CMS cannot handle high traffic, causing customers to abandon carts and turn towards competitors. The only solution is to migrate the website to a more suitable platform.

Causes of Technical Debt

There are four types of root causes for tech debt:

• Business causes: Company needs sometimes stand in the way of the best development practices. Pressures to release products faster or for less money are common causes of tech debt.
• Context switches: Sometimes, plans that made sense for the initial design stop making sense over time. Tech stacks change and systems get outdated, so teams often take shortcuts to keep the system operational and (somewhat) up-to-date.
• Development causes: Development-based causes happen when you introduce insufficient resources, poor documentation, and a lack of testing to the coding process.
• People-based causes: Lack of experience or motivation, poor communication, distributed teams, and shifting resources are common causes of tech debt.

Here are some real-life examples of tech debt causes:

• An unreasonable deadline that pressures the team into a quick release.
• Using an easier, familiar platform instead of an optimal one.
• Low-quality software design decisions.
• Poor up-front definition of project goals.
• Lack of coding skills.
• Lack of product ownership.
• Relying on quick and risky band-aid fixes instead of complete refactoring.
• Insufficient testing (QA and QC).
• Poor understanding of software architecture.
• Writing code without referring to supporting documentation.
• Urgent, last-minute changes to specifications.
• A long series of product improvements by different developers.
• Parallel development on multiple branches that require merging in the future.

Measuring Technical Debt

Here are the metrics that help assess the level of technical debt at your organization:

• New bugs vs. closed bugs: If developers create a note when they fix a bug, you can calculate how effectively the team eliminates tech debt. If new bugs outnumber closed ones, you should look to make some changes.
• Code quality: Code quality quantifies the overall state of code by calculating cyclomatic complexity, class coupling, lines of code, and the depth of inheritance. Higher code quality scores imply less technical debt within the product.
• Cycle time: This metric measures the time between the first commit and deployment. Short cycle times indicate a low technical debt.
• Code churn: This metric reveals the number of times the team rewrites or replaces a line of code after the launch. Prolonged high churn in any code area indicates that iterations have mistakes or quick fixes.
• Code coverage: This metric measures how much code gets executed when running a testing suite. Code coverage reveals how efficient code is by assessing the number of unused lines.
• Technical debt ratio (TDR): TDR helps calculate the overall future cost of technical debt. This metric is a ratio of the cost to fix a system (remediation cost) and the cost of developing the system (development cost).

How to Reduce Technical Debt?

There is no one-size-fits-all recipe for reducing technical debt. Some tactics that work for a small startup do not always work for a 100+ people team fixing issues on an enterprise-level system. However, there are two general directions every company should take to keep tech debt under control:

• Minimize the creation of new tech debt.
• Pay back existing debt as efficiently and regularly as possible.

Let us look at different best practices and strategies you can use to keep current technical debt in check and limit the number of new bugs popping up.

Track and Cut Out the "Cruft"

Tracking and removing the cruft is vital as a tech debt can survive multiple development cycles. Dealing with craft is a five-step process:

• Inventory of your tech debt: Start and maintain a list of technical debts in your company. Keep track of all instances where the team knows the code is not clean and releases that require future reworks.
• Categorize the cruft: Group tech debts into workable units based on their complexity, cost of fixing, and potential impact.
• Appraise the debt: Note the consequences of ignoring each unit. This descriptive metric helps with task prioritization.
• Make the list accessible: The cruft list should be visible to all relevant parties in your company (stakeholders, marketing, sales, SecOps, etc.).
• Remove cruft early and often: Schedule regular (and frequent) times for developers to pay off tech debt and keep the product clean.

This process should be continuous and a part of every release cycle. Ideally, cruft tracking and removal should be one of the KPIs of your development or DevOps team.

Do Not Hire Low-Quality Developers

Low-quality, cheap developers create more tech debt even when actively solving existing bugs. When you account for the lost revenue from delivering a less performant product, low-quality developers cost you more than what you would pay for an experienced team.

When hiring developers, you should embrace the following two mindsets:

• Value over price.
• Quality over quantity.

Smaller, better teams operate better than bigger, less skilled departments. Hiring two top-tier developers is typically a better option than going with ten underperforming coders. Once you have two reliable engineers to dictate the direction and supervise releases, you can start bringing in junior-level staff members for in-house training.

Write High-Quality Code

This practice ties in with the one above; ensure the team writes quality code by measuring the following metrics:

• Code complexities (cyclomatic and cognitive).
• Class coupling.
• Lines of code.
• The depth of inheritance.
• Arity.
• Maintainability index.
• Halstead complexity measures.
• Time to write n lines.

Keeping an eye on these metrics helps ship low-debt software products. Remember to reward staff members based on high-level work and not on the amount of written code.

Consider also creating a coding style guide. By documenting ideal coding practices, the team will find it easier to write cleaner syntax and spend more time reviewing the code.

Use Automated Instead of Manual Testing

Manual testing is not a long-term option for controlling tech debt, which is why your team should instead look to set up and rely on automated testing. While establishing and maintaining automated testing takes time and effort, the lack of manual tests will ensure you uncover cruft more precisely and consistently.

Keep a Transparent Record of Changes

The development team should keep an ongoing record of all changes in a repository. If a problem occurs, developers can easily trace its source and document the debt.

This record is also helpful for distributed teams and highly complex projects requiring careful changes (such as migrating to the cloud or modernizing legacy software).

Create a Tech Debt Team

Not every developer or stakeholder should make decisions on tech debt. Decisions should come from qualified team members who understand the project and have experience with product tradeoffs.

Consider creating a dedicated team within your company that makes tech debt-related decisions. This team should:

• Have in-depth knowledge of your product.
• Have experience with making strategic tradeoffs between quality and speed.
• Be transparent with the reason why the team is taking on debt.
• Communicate the purpose of the debt with upper management in a non-technical way.
• Outline an optimal remediation approach.
• Create a roadmap that explains who, when, and how the team will repay the debt.
• Ensure developers stick to the plan and iron out the tech deficit in the agreed timeline.

Not every opportunity is worth getting into debt for, so the dedicated team should also evaluate where the option lies on the Tech Debt Wall.

Set Aside Time and Resources to Tackle Debt

Prioritizing good documentation and quality code is vital, but you also need to ensure your team has enough time and resources to deal with tech debt. Debugging products and solving issues is resource and time-consuming, so developers will not be able to solve debt-related problems if they are under non-stop pressure to deliver new features.

Experts suggest that an average Scrum team should allocate 15 to 20% of their sprint cycle to refactoring code and fixing debt-related bugs.

Ensure Regular Code Refactoring

Your team should perform regular code refactoring (or application refactoring) to ensure continuous payoffs of tech debt. Refactoring is a process of restructuring messy code segments to make them more:

• Understandable.
• Maintainable.
• Reliable.

Re-writing components in a software product removes redundancies and improves performance, both of which are vital to tech debt payoff. You should also consider improving the team's code review procedures and introducing code linting (automated checks of source code for programmatic and stylistic errors).

Adjust Your Company's Definition of "Done"

Develop a repeatable formula that instructs how developers conduct experiments or add new features to the product. The procedure should include a standard for manageable tech debt, so the team should not consider any product as "done" until the software meets the set requirements.

Strike the Right Balance Between Speed and Quality

As long as your team understands that they must "repay" their tech debts, taking strategic shortcuts and occasionally trading off quality for speed can give you a considerable competitive edge. Quick time-to-market and speedy proofs-of-concept are everything in today's market, so use tech debt wisely and ensure the team proactively manages the balance to avoid future roadblocks.