The Creep of Technical Debt
A guide to understanding, managing, and prioritizing the inevitable accumulation of technical debt
This will be a brief post due to travel constraints.
Technical debt is a frequently misused term that has lost its gravity in business contexts. Non-technical leaders often struggle to grasp its meaning, and depending on company culture, it can create friction between technical and non-technical teams.
But why does every software endeavor create technical debt, and can we find a solution?
What Is Technical Debt?
Technical debt is often compared to financial debt to explain the concept. When taking on financial debt for investments, you know you'll need to pay it back—not immediately but over time. The payback terms can vary, such as monthly payments or a lump sum at the end.
This analogy works well since technical debt is often incurred to reach the market faster. You knowingly take it on to deliver a product. However, technical debt is more complex than financial debt because it can grow in various ways.
To understand this—staying with the financial analogy—every line of code written is a liability. It may work perfectly today, but break tomorrow. Why? Because unlike in the early days, software no longer exists in isolation. For a web application, technical debt can accumulate when browsers update, adding or deprecating features.
Consider Flash, which was widely used in the mid-2000s until Adobe announced in 2017 that it would stop updating. This example shows a relatively long period with a decent transition time. But there are more severe cases, like security vulnerabilities in your software.
As everything is now interconnected, every software component must stay up-to-date to remain secure. This creates technical debt automatically without changing a single line of code.
So technical debt is inevitable. You either have or will have technical debt from the moment you write code.
Managing Technical Debt
Since technical debt is unavoidable in software development, the key question becomes: how can we keep it under control?
It depends on the product and its longevity. For products built to last, the first step is avoiding unnecessary technical debt by using current frameworks, techniques, and architectural designs.
The most crucial aspect is consistent maintenance of technical debt. Companies must allocate time for their teams and engineers to address it. While this time might occasionally be used for other tasks, it shouldn't be an excuse to eliminate maintenance periods altogether. Non-technical leaders often question the business value of this work, and engineers sometimes struggle to articulate the benefits since the problems often lie in the future.
The Playhouse Analogy Consider a wooden playhouse in your garden as an analogy. You start with quality wood (equivalent to our coding frameworks) and good tools to build it. A playhouse built with these materials will naturally last longer.
However, erosion is inevitable. Nature will take its toll on the playhouse—but imagine software aging 100 times faster. Without regular repairs and maintenance, the structure will eventually collapse.
The business value of managing technical debt is, therefore, twofold:
Keeping your product viable
Maintaining its adaptability
Here's another example: imagine building a product on a framework that will be deprecated in three years. Without starting the transition today, your entire investment could be lost. For complex products, a complete reimplementation might be impossible.
To maintain control, dedicate fixed time for maintenance. While this might decrease during busy periods, it should never drop to zero. If business pressures consistently override maintenance, you'll face much larger costs later—like compound interest that becomes too large to pay.
A good rule of thumb is to allocate 20-30% of team resources to addressing technical debt and maintenance.
Prioritizing Tech Debt
Even with the dedication of 20-30% of resources to maintenance and occasional drops to 5-10% during business pressure, technical debt will still accumulate. Therefore, it's crucial to distinguish between two types of debt:
Debt that could break your business
Debt that can wait
This is similar to financial investments—some debts can be managed over time when conditions are stable, while others, like loans with variable interest rates, could potentially destroy your business.
Critical Technical Debt Examples:
Security vulnerabilities that could lead to devastating breaches
Aging frameworks being discontinued, potentially affecting core components like payment systems
In the best-case scenario, such critical technical debt is recognized by everyone and prioritized with the same urgency as features or bug fixes. When this happens, the business side never notices issues because technical teams are already addressing future challenges.
This proactive approach is crucial because technical debt can block business growth at the worst possible times—for example, when competitors are gaining market share, and you're unable to deliver new features.
Takeaway
Technical debt isn't easy to understand and is often perceived as a business blocker rather than an enabler. When delivering software, you must accept technical debt—just as a house deteriorates due to natural forces. With software, however, these external influences act much more rapidly.
Communicating Technical Debt to Leadership
Engineers should communicate with non-technical leaders using concrete data. How?
Present the impact through numbers and metrics
Cite specific examples where technical debt slowed business goals
Share metrics about incidents and vulnerabilities that stemmed from delayed maintenance
For managers:
Give your teams breathing room, even under severe business pressure. The only exception might be when the company's survival is at stake—in such cases, normal rules can be temporarily suspended. But don't let this continue for long, or your software will deteriorate to a point where only massive investments can save it.
Consider it this way:
Think of technical debt as an ongoing financial commitment
Make regular, small payments through maintenance
Accept that it's a debt you'll never fully pay off