An Introduction to Tech Debt | Ardoq

Technical debt is an inevitable consequence of business growth. At some point in time, the decision has to be made to prioritize other activities important to the business over technical work. However, once debt gets beyond an acceptable amount, it can impede an organization's ability to grow and digitize properly. This is why it is vital that tech debt is monitored and managed correctly.

For many organizations, the problem is already significant:  Forbes estimates Engineers spend 33% of their time dealing with it, while a McKinsey survey indicated that 60% of CIOs believe their organization's tech debt has increased noticeably over the past three years.

The problem will get even worse as organizations rush to implement and reap the rewards of emerging technologies like AI before doing the necessary work to improve what they already have and the systems they depend on.

"Adding AI on top of technical debt and a messy application portfolio isn't only difficult, it may be directly irresponsible. If you don't have a proper IT portfolio overview, you don't have control, and you won't be able to extract value from the new technologies," says Erik Bakstad, former Enterprise Architect and now CEO of Ardoq. 

Shortcuts

What is Technical Debt?
Technical Debt: A Basic Definition
Why Does Tech Debt Occur?
Types of Technical Debt
Is Technical Debt Bad?
How Does Tech Debt Impact Your Organization?
How To Measure Tech Debt
How to Manage Tech Debt in 9 Steps
What Are the Benefits of Managing Tech Debt?

What is Technical Debt? 

One of the most common forms of technology risk, technical debt, or tech debt, commonly refers to the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. Definitions can vary because the term has evolved over time.

No matter how you define it, tech debt, like other forms of debt, accrues "interest" in the form of cost, inefficiency, risk, and customer dissatisfaction. Any failure to address tech debt will result in the growth of this interest, potentially exponentially. For example, not dealing with a quick fix for software could tie up significant resources with future troubleshooting or system upgrades. 

It is, therefore, essential that you identify, measure, and manage tech debt.

Technical Debt: A Basic Definition

Technical debt is essentially work required on a technological solution that is delayed because of other priorities. It occurs when organizations choose not to fix issues straight away for short-term gain—but it can affect long-term quality.

An Academic Definition of Technical Debt

The research paper Towards an Ontology of Terms on Technical Debt says that technical debt is "a term that has been used to describe the increased cost of changing or maintaining a system due to shortcuts taken during its development."

In the early days, tech debt had a narrow definition. Ward Cunningham determined that "Technical debt arose because software developers made a conscious decision to cut corners when they were writing software." This decision may have been deemed necessary at the time, but it came at a cost because the software could have been built better, and there was a gap between what was delivered and what could have been achieved. This gap, called 'tech debt,' was the cost of future reworking needed to fix the software.

Over the years, the definition of tech debt has become broader, and today, the term has evolved to include a much wider range of system deviations. Some may even say that tech debt is any gap between what a system delivers and what is wanted! 

Gartner succinctly states that "Technical debt can be summarized as the future liabilities and risks that are created by suboptimal decisions, natural entropy of systems, out-of-date dependent components, new security and vulnerability threats, and changed or new requirements."

Why Does Tech Debt Occur?

Tech debt can occur for a number of reasons, either deliberate or inadvertent. Deliberate technical debt can result from shortcuts taken in software development or implementation to speed up delivery. Inadvertent tech debt may occur because standards have changed or an organization has learned something new compared to when the solution was first developed.

For example, an organization might deliberately cut corners to pursue first-mover advantages in implementing a technical solution, onboarding debt in the short term, and planning remediation in the longer term.

The reasons for technical debt may include:

Business Strategy

• Lack of understanding of the business strategy.
• Poor alignment between the business strategy and IT.
• Insufficient funding to support the business strategy.
• Excessive complexity in products, processes, or applications.

IT Environment

• Changing or evolving requirements, common during transformation projects, can lead to short-term and non-optimal solutions.
• Time pressure can lead to shortcuts or the implementation of quick fixes to meet deadlines, typically sacrificing best practices.
• Lack of resources, such as time, budget, or expertise, can compromise solution quality and architectural decisions.
• Limited knowledge or inexperienced specialists may make suboptimal design choices.
• Technical constraints imposed by existing systems or frameworks can force architects to make trade-offs that prioritize functionality over long-term maintainability or scalability.

Types of Technical Debt

The previously mentioned research paper Towards an Ontology of Terms on Technical Debt proposes fourteen categories of technical debt in order to create a formalized, agreed understanding. Although these are key types of tech debt, this list is not exhaustive.

• Architecture Debt: Problems encountered in project architecture that can affect architectural requirements such as performance or robustness.
• Build Debt: Build-related issues that make the process of building more difficult and require more time and resources.
• Code Debt: Problems found in the source code that make it less understandable and difficult to maintain.
• Defect Debt: Defects in the code that, although identified, have not been prioritized for fixing.
• Design Debt: Debt discovered in code that does not follow the principles of good object-oriented design.
• Documentation Debt: Problems found in software project documentation, such as missing, inadequate, or incomplete documentation.
• Infrastructure Debt: Issues in organizational structure that delay or hinder development activities.
• People Debt: People issues affect development, such as having too few people in different knowledge areas.
• Process Debt: Inefficient processes, such as those ill-suited for handling what they are used for.
• Requirement Debt: Requirements that haven't been implemented completely, such as those that are implemented but do not fully satisfy non-functional requirements.
• Service Debt: A need to substitute a web service.
• Test Automation Debt: Work required to automate tests and support a faster development process.
• Test Debt: Issues that can affect testing activities, such as inadequate testing tools or planned tests that were not run.

Is Technical Debt Bad?

When developing systems, some tech debt is inevitable, and it can be difficult to avoid completely. It is debt in the sense that it eventually has to be 'paid' back in work. The question is how much the organization can handle before it reaches critical mass and has negative impacts.

In the rush to release a product, it may be decided to amass some tech debt now and address it later in order to stay on schedule. But this trade-off needs to be considered carefully. Consider too, that different parts of the organization may have different perspectives on tech debt. Technical teams wish to be as close to zero as possible, while business staff may wish for more leeway in order to align with organizational goals.

Why is Tech Debt Difficult to Solve?

According to Gartner, there are three simple reasons why technical debt can be difficult to solve. 

1. It's cheaper and easier in the short term to delay upgrades.
2. Maintenance is less attractive to organizations than new initiatives.
3. It's hard for stakeholders to agree on priorities.

These factors come down to incentives: it's attractive for businesses to delay addressing technical debt because they don't want to or don't know how to deal with it. However, there comes a point when the short-term benefits are outweighed by the long-term costs of having a deficient product or ineffective organization.

How Does Tech Debt Impact Your Organization?

Over time, tech debt can accumulate and negatively affect your organization in several ways:

• Decreased system quality: Quick fixes and shortcuts often introduce bugs and defects, which, when accumulated, make business systems brittle and prone to failure.
• Increased system fragility: Shortcuts during system development or maintenance often lead to tightly coupled systems with interdependent components. As the number of connections increases, so does the risk that changing one part of the system will negatively impact another.
• Reduced flexibility and agility: Tech debt can hinder a company's ability to respond to evolving business needs, as carrying technical debt makes it more difficult to make feature changes and upgrades.
• Limited innovation: Dealing with tech debt ties up resources, leaving less time for IT to work on modern technologies and innovation.
• Performance issues: Tech debt leads to inefficient solutions that consume more resources and reduce a system's overall performance.
• Scaling challenges: Systems burdened with tech debt may not scale effectively to handle increased loads, leading to performance bottlenecks and potential system outages.
• Operational risks: When issues arise, systems with high tech debt can take longer to recover due to the complexity and interconnectedness of the solution. They can also be subject to more frequent downtime, impacting business operations and customer trust.
• Security vulnerabilities: Quick fixes and inadequate solutions leave the system vulnerable to attacks and exploitation. In addition, high tech debt can lead to inconsistent or delayed security patching, further compromising the system's security.
• Increased maintenance costs: The cost and effort required to fix issues increases, straining resources and budgets, whilst making it harder to invest in improvements.
• Resource drain: Significant time and resources can be spent managing and reducing tech debt instead of enhancing system resilience and functionality.

In summary, tech debt makes systems more fragile, less flexible, and harder to maintain. To ensure long-term resiliency, it is crucial to manage and reduce technical debt by applying best practices in software development, doing regular refactoring, and investing in quality and maintainability.

How to Measure Technical Debt

Tech debt needs to be documented and measured in order to decide what should be done about it. Can it be lived with, and if not, how should it be handled?

Before you can measure technical debt, you should have a clear understanding of what you want to achieve and, as a minimum, make sure you have an inventory of your applications. If your application repository is outdated or missing information, managing tech debt will be challenging.

Read our article for tips on mastering application inventory management.

Once you have documented your applications, you can determine how best to measure tech debt. Over time, numerous methods have been devised, including two well-recognized approaches: the Gartner method and the SQALE method.

The SQALE method

This method proposes relating the cost of remediation to the cost of the debt's business impact if nothing is done. It estimates the financial cost of remediating quality issues and compares it to the cost of living with the debt. This can be useful to demonstrate the tangible impact of the debt to stakeholders who are cost-motivated.

The Gartner method

This proposes considering tech debt as a source of risk, asking, "Should the unthinkable happen, what negative impact will tech debt have on the business?" It proposes using a 1-5 scale to measure the worst possible impact of the debt and compare this to the likelihood of this impact happening while also considering the cost of remediation.

These models use different metrics and can, therefore, be used separately or together.

By measuring tech debt, CIOs and business leaders can better address, understand, and prioritize efforts to reduce debt, not only in terms of money but also in terms of business impact.

How to Manage Tech Debt in 9 Steps

To be able to reduce tech debt, you must first understand the level of it the organization currently has. These are the key steps necessary for reducing tech debt:

1. Use either cost or risk-based measurements to determine the areas affected by tech debt and create a tech debt backlog.
2. Assess the business impact arising from each tech debt item, including which capabilities or organizational units are affected and how seriously.
3. Determine the effort required to resolve each tech debt item according to the organization's needs (budget, impact, customer satisfaction, and development efficiency).
4. Prioritize the items in the backlog based on the output from step 2.
5. Plan and allocate resources to address tech debt items.
6. Refactor and fix components.
7. Test and validate.
8. Monitor and measure progress for each activity.
9. Continuous improvement to reassess priorities, adjust resource allocation, and evolve system standards and practices to prevent new tech debt.

Tech debt reduction is an ongoing effort and should be integrated into the development process rather than considered a one-time project. By following this process and consistently addressing tech debt, organizations can gradually reduce its impact and create a healthier IT environment.

As an example, Innovation Norway needed to communicate to their management the time and effort needed to reduce their tech debt. Specifically, they had to identify the number of integration components that needed updating to the latest version of the .NET framework and provide accurate timeframes for delivery, estimated costs, and financial consequences if not upgraded.

Application portfolio information was collected and a tech debt backlog created, allowing management to make strategic decisions including understanding the impact of change through dependency mapping, improving governance, driving decision-making about their portfolio, facilitating business case and impact analysis processes, and reducing unnecessary renewals.

What Are the Benefits of Managing Technical Debt?

Where tech debt has been identified as an issue for the organization, the proactive and effective management of it can bring numerous benefits:

• Improved solution quality: Enhanced system quality and reliability, leading to fewer bugs, reduced downtime, and better overall user experience.
• Enhanced development speed: Designers and developers spend less time fixing issues or developing workarounds and more time delivering new features and functionality.
• Increased agility and adaptability: Organizations can be more agile and responsive to changing business needs and market trends. 
• Reduced risk and regulatory scrutiny Through improved security and resilience. 
• Cost savings: Although upfront investment may be required to remove or reduce tech debt, cost savings can be achieved in the long run. By proactively addressing tech debt, organizations can avoid costly firefighting situations, reduce maintenance costs, and avoid potential revenue losses due to system failures.
• Enhanced resource allocation: Organizations can allocate development resources more effectively.
• Improved customer satisfaction: Removing tech debt results in higher system quality, fewer bugs, and a better user experience, leading to increased customer satisfaction, loyalty, and positive brand perception.
• Attraction and retention of talent: Organizations can attract and retain top talent who value working on quality systems and innovative projects rather than tech debt-related issues.

Overall, actively managing tech debt helps organizations create a healthier IT and business environment, improve their competitive advantage, and drive long-term success.

Track, Quantify, and Manage Technical Debt With a Ready-to-Use Solution

Tech debt has grown from a term applied to software development to any type of system deviation from functional and non-functional requirements. Under this definition, tech debt is prevalent in every industry, and IT leaders need to gain control of it.

One of the best ways to do this is through Enterprise Architecture software like Ardoq. It can help you to:

• Get control of the organization's application portfolio.
• Measure tech debt and understand where it is causing intolerable risk or impacting the ability to execute or modernize.
• Set objectives for reducing tech debt and monitor, on an ongoing basis, how well they are being met.

Learn more about how Ardoq can help you manage and measure tech debt by visiting our tech debt solution page.

FAQs About Technical Debt

How to Identify Technical Debt

One key indicator of tech debt in applications is “code smells,” issues in source code that, although they don’t prevent the code from working, are indicative of a deeper problem. They should be easy to spot as they sit on the surface, but they can be tricky to fix, for example, requiring the same change to be made in multiple places.

Another way to identify tech debt is through user feedback. If users are unhappy with a software’s UI or performance, this is work that needs to be done, even if it is less enticing than adding new features or functionality.
Finally, you can track the maintenance metrics about the code. If bugs are discovered frequently or, in general, fixes are taking a long time to implement, this can be indicative of a high amount of tech debt.

Who is Responsible For Technical Debt?

One of the issues preventing organizations from addressing tech debt properly is deciding who should be responsible for it. And there’s no easy answer—it’s a topic with multiple schools of thought that may require some experimentation.

In software development, it is the developers who will fix the debt. But should they be responsible for decisions the business made, and are they the right people to decide priorities? It could make more sense for the product manager (or in Scrum, the project owner) to be in charge, but they may lack the technical expertise to contribute meaningfully to discussions.  As a connection to the wider business, however, they may have a good handle on what should be prioritized.

Another perspective is that technical debt offers the opportunity for IT to step up and lead, making the case for what debt needs to be prioritized and bridging the gap between tech needs and business needs.

Essentially, it depends on the organization, and what works for some may not work for others.