What is technical debt? Can we even define technical debt? It might not be what you think. Let's dig into details.
Technical debt definition
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.
What if 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.
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?
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 technical debt metaphor has lasted since the 1990s, it is in large part because it captures how tech 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.
-2.svg)
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.
See the problem with tech debt - 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.
