Book a demo
TECHNICAL DEBT

What is technical debt?

Can we even define technical debt?
It might not be what you think.

Start free trial Test it live
Trusted by

Definition of technical debt

There are different ways to define technical debt. The metaphor was introduced by Ward Cunningham in the 1990's. As the world's codebases grow older and larger, the term has become more and more widely used to address a reality felt by companies, managers and developers every day.

It might be tempting to think of it as simply "everything that's wrong with a codebase". However, just saying "bad code" misses the point for a few reasons: 

No one has ever been able to define a universal standard for how code should be. Different schools of thought propose different models.

Development is always contextual, influenced by business needs, available technologies, and the composition of a development team.

Deciding what perfect code would look like is an impossible task in itself. What is correct in one context might not be correct later.

There are limits to what can be achieved by measuring code against an impossible or imaginary scale.

CodeScene's system map showing file-level hotspots in a codebase.

CodeScene's system map showing file-level hotspots in a codebase.

There are different ways to define technical debt. The metaphor was introduced by Ward Cunningham in the 1990's. As the world's codebases grow older and larger, the term has become more and more widely used to address a reality felt by companies, managers and developers every day.

It might be tempting to think of it as simply "everything that's wrong with a codebase". However, just saying "bad code" misses the point for a few reasons: 

No one has ever been able to define a universal standard for how code should be. Different schools of thought propose different models.

Development is always contextual, influenced by business needs, available technologies, and the composition of a development team.

Deciding what perfect code would look like is an impossible task in itself. What is correct in one context might not be correct later.

There are limits to what can be achieved by measuring code against an impossible or imaginary scale.

A problem only becomes technical debt when it negatively impacts future progress. A better definition of technical debt would be: the aspects of a project that make future work harder, riskier or costlier. Problematic code becomes technical debt when it is one of the forces holding your teams and your company back.

 

The advantage of this approach to technical debt is that it focuses on real-world consequences. This opens the door to reliably measuring technical debt by looking in code for predictors of future slowdowns. And this also means that if we try to fix technical debt, we are fixing the things that will have a measurable impact, in terms of time and cost.

A bar chart showing the decrease in time available for feature development and increase in time wasted struggling with technical debt over time.

A bar chart showing the decrease in time available for feature development and increase in time wasted struggling with technical debt over time.

A problem only becomes technical debt when it negatively impacts future progress. A better definition of technical debt would be: the aspects of a project that make future work harder, riskier or costlier. Problematic code becomes technical debt when it is one of the forces holding your teams and your company back.

 

The advantage of this approach to technical debt is that it focuses on real-world consequences. This opens the door to reliably measuring technical debt by looking in code for predictors of future slowdowns. And this also means that if we try to fix technical debt, we are fixing the things that will have a measurable impact, in terms of time and cost.

Technical debt is an inevitable byproduct of
software development

Change happens

Change is an inevitable dimension of software. Business needs evolve. Companies grow and ask more of their software. New technologies arise.

 

It is extremely rare that we can say that a software project is definitely "correct" or even "done".  Programs only stop changing when no one uses them anymore.

 

Lehman’s law of Continuing Change expresses this:

 

“A program that is used and that as an implementation of its specification reflects some other reality, undergoes continual change or becomes progressively less useful. The change or decay process continues until it is judged more cost effective to replace the system with a recreated version.”

 

If change is inevitable, the key is how we, and our software, handle it.

Code Health graph in CodeScene with a high resolution view of average code health trend.

Change happens

Code Health graph in CodeScene with a high resolution view of average code health trend.

Change is an inevitable dimension of software. Business needs evolve. Companies grow and ask more of their software. New technologies arise.

 

It is extremely rare that we can say that a software project is definitely "correct" or even "done".  Programs only stop changing when no one uses them anymore.

 

Lehman’s law of Continuing Change expresses this:

 

“A program that is used and that as an implementation of its specification reflects some other reality, undergoes continual change or becomes progressively less useful. The change or decay process continues until it is judged more cost effective to replace the system with a recreated version.”

 

If change is inevitable, the key is how we, and our software, handle it.

A new situation arises that the design didn't anticipate.  "We can add a null check…, or one more argument…, or one more if statement…".

 

At the simplest level, these small steps that do not readapt the design of the system are how a program becomes more brittle and less resilient over time.

 

This is where Lehman’s second law, the law of Increasing Complexity, comes into play:

 

“As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.”

 

In other words, as we deal with change (which we recognize as inevitable), we increase the complexity of the code and degrade the underlying model.

 

The consequence is a reduction in what Lehman calls the program’s alterability. The code becomes harder to change the next time; future changes will be more expensive and be associated with higher risks. 

CodeScene's system map with a Complexity trend graph that shows gradual increase in code complexity with an increase in lines of code.

CodeScene's system map with a Complexity trend graph that shows gradual increase in code complexity with an increase in lines of code.

A new situation arises that the design didn't anticipate.  "We can add a null check…, or one more argument…, or one more if statement…".

 

At the simplest level, these small steps that do not readapt the design of the system are how a program becomes more brittle and less resilient over time.

 

This is where Lehman’s second law, the law of Increasing Complexity, comes into play:

 

“As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.”

 

In other words, as we deal with change (which we recognize as inevitable), we increase the complexity of the code and degrade the underlying model.

 

The consequence is a reduction in what Lehman calls the program’s alterability. The code becomes harder to change the next time; future changes will be more expensive and be associated with higher risks. 

Technical debt doesn’t just mean “bad code”

The following paragraph, written over forty years ago, encapsulates much of the challenge of technical debt:
 
“the need for continuing change is intrinsic to the nature of computer usage. […]  The unit cost of change must initially be made as low as possible and its growth, as the system ages, minimized. Programs must be made more alterable, and the alterability maintained throughout their lifetime.”

Change is inevitable. Can your code handle it?

Is your software alterable, as Lehman would say? Can it adapt easily to the changes that will be required?

Will each round of changes make it more brittle, in a spiral of increasing costs, or will the organization perform the necessary work to maintain its adaptability?

Technical debt is not just the cost of change, it is that loss of alterability that makes change progressively more expensive.

What we refer to as “technical debt” is really an increasing “unit cost of change” over time.

CodeScene's system map showing the distribution of files with healthy, problematic and unhealthy code in a codebase.

CodeScene's system map showing the distribution of files with healthy, problematic and unhealthy code in a codebase.

The following paragraph, written over forty years ago, encapsulates much of the challenge of technical debt:
 
“the need for continuing change is intrinsic to the nature of computer usage. […]  The unit cost of change must initially be made as low as possible and its growth, as the system ages, minimized. Programs must be made more alterable, and the alterability maintained throughout their lifetime.”

Change is inevitable. Can your code handle it?

Is your software alterable, as Lehman would say? Can it adapt easily to the changes that will be required?

Will each round of changes make it more brittle, in a spiral of increasing costs, or will the organization perform the necessary work to maintain its adaptability?

Technical debt is not just the cost of change, it is that loss of alterability that makes change progressively more expensive.

What we refer to as “technical debt” is really an increasing “unit cost of change” over time.

What we refer to as “technical debt” is really an increasing “unit cost of change” over time.

When the debt is not paid off, this cost rises until it can no longer be paid, and the project is abandoned.

If the debt metaphor has lasted since the 1990s, it is in large part because it captures how technical debt compounds, just like interest on financial debt.

Technical debt is not the cost of change, it is the increasing cost of change.

The situation will not improve without taking specific efforts to reverse the trend, taking specific steps to improve the code and prepare for future changes.

A line chart showing relationship between technical debt and delivery efficiency.

A line chart showing relationship between technical debt and delivery efficiency.

What we refer to as “technical debt” is really an increasing “unit cost of change” over time.

When the debt is not paid off, this cost rises until it can no longer be paid, and the project is abandoned.

If the debt metaphor has lasted since the 1990s, it is in large part because it captures how technical debt compounds, just like interest on financial debt.

Technical debt is not the cost of change, it is the increasing cost of change.

The situation will not improve without taking specific efforts to reverse the trend, taking specific steps to improve the code and prepare for future changes.

The hidden cost of technical debt

At the same time as the software industry is struggling with recruiting enough talent, research indicates that up to 42% of developers’ time is wasted dealing with Technical Debt where the cost of subpar code alone comes to $85 billion annually.
– Adam Tornhill and Markus Borg, Code Red, 2022

What is the true cost of technical debt? The software industry is learning the hard way.

 

Recent research shows how to quantify that cost. Compared to healthy code, problematic code produces significantly more bugs over time. It also increases costs by slowing development. Development has shown to be 124% faster in healthy code.

Read the Code Red Whitepaper

A bar chart showing the additional time spent in development when working with unhealthy code compared with healthy or problematic code.

A bar chart showing the additional time spent in development when working with unhealthy code compared with healthy or problematic code.

What is the true cost of technical debt? The software industry is learning the hard way.

 

Recent research shows how to quantify that cost. Compared to healthy code, problematic code produces significantly more bugs over time. It also increases costs by slowing development. Development has shown to be 124% faster in healthy code.

Read the Code Red Whitepaper

Interest cost of technical debt:

Developer time

Support issues from customers experiencing bugs

Opportunity cost of the features that will never be built

A bar chart showing the additional time spent in development when working with unhealthy code compared with healthy or problematic code.

A bar chart showing the additional time spent in development when working with unhealthy code compared with healthy or problematic code.

Interest cost of technical debt:

Developer time

Support issues from customers experiencing bugs

Opportunity cost of the features that will never be built

Modern companies and their teams try to be lean and agile. This becomes more difficult when they are burdened with code that takes excessive amounts of time to maintain and slows down the implementation of new features.

 

The cycle of increasing complexity and increasing costs for handling change is directly at odds with the desired agility. This is often when organizations start paying closer attention to technical debt and looking for solutions to handle it. 

Modern companies and their teams try to be lean and agile. This becomes more difficult when they are burdened with code that takes excessive amounts of time to maintain and slows down the implementation of new features.

 

The cycle of increasing complexity and increasing costs for handling change is directly at odds with the desired agility. This is often when organizations start paying closer attention to technical debt and looking for solutions to handle it. 

See the problem and talk about it

Development costs, bugs and unmet deadlines are visible to everyone in an organization. Yet the underlying causes are often hard to identify. For many stakeholders, especially those who are at a greater distance from the code, the root causes remain hidden in a "black box".

 

Large software projects are complex and hard to understand. Technical debt makes this worse. As a result, many stakeholders only see the impact of the technical debt, and not underlying issues. Moving toward a solution becomes difficult, because for many of the decision makers the real problem is invisible.

See the problem and talk about it

Development costs, bugs and unmet deadlines are visible to everyone in an organization. Yet the underlying causes are often hard to identify. For many stakeholders, especially those who are at a greater distance from the code, the root causes remain hidden in a "black box".

 

Large software projects are complex and hard to understand. Technical debt makes this worse. As a result, many stakeholders only see the impact of the technical debt, and not underlying issues. Moving toward a solution becomes difficult, because for many of the decision makers the real problem is invisible.

To break out of situations like this, companies require clear, authoritative metrics, with a data-driven approach that cuts through the fog and the uncertainties. CodeScene pinpoints the exact locations of the most expensive parts of the codebase, and offers a fact-based path forward that can be communicated to all the technical stakeholders, from development teams to the CTO.

 

See how CodeScene can help you identify and reduce your technical debt.

Focus on the code that matters-2

Focus on the code that matters-2

To break out of situations like this, companies require clear, authoritative metrics, with a data-driven approach that cuts through the fog and the uncertainties. CodeScene pinpoints the exact locations of the most expensive parts of the codebase, and offers a fact-based path forward that can be communicated to all the technical stakeholders, from development teams to the CTO.

 

See how CodeScene can help you identify and reduce your technical debt.

Start paying down your technical debt today.

Start a free trial or book a demo with our team.

Start free trial Book a demo
New visual identity
New website
new product interface
CodeScene just got a new look!

The new identity revolves around our vision to “give code an intelligent voice” and reflects our forward-looking culture. The new logo reinforces the idea of artificial intelligence and CodeScene being there as an extra team member, guiding you toward better software and teams.

The new website presents relevant content in a clean, minimalistic and modern way with an aim to give visitors easy access to solutions and information.

We are proud to share this new identity with our community and hope that it will inspire all of us to write better code, build happier teams and future proof our software.