There are different ways to define technical debt. The metaphor was introduced by Ward Cunninghamp 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.
There are different ways to define technical debt. The metaphor was introduced by Ward Cunninghamp 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Developer time
Support issues from customers experiencing bugs
Opportunity cost of the features that will never be built
Developer time
Support issues from customers experiencing bugs
Opportunity cost of the features that will never be built
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.
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 free trial and get started with CodeScene today or book
a demo with our team.
