There's a cost item that doesn't appear in any budget, doesn't surface in budget meetings, and doesn't appear on CFO dashboards. Yet, in many companies, it's one of the IT department's most significant expenses.
It's called technical debt. And it's the kind of problem that grows silently until it becomes impossible to ignore—often at the worst possible time.
What is technical debt, in plain English?
The term was coined in the 1990s by Ward Cunningham, one of the pioneers of Agile, with a simple and powerful analogy: writing fast but suboptimal code is like taking on a financial loan. It works in the short term, but over time it accumulates interest that you must repay sooner or later.
In practice, technical debt arises whenever a suboptimal technical choice is made—consciously or otherwise. Some common sources:
- Code written in a hurry to meet a deadline, without following best practices
- Add functionality on top of functionality without rethinking the overall architecture
- Libraries and dependencies not updated for months or years
- Automated tests were never written, because "there was a rush"
- Missing or obsolete documentation
- Architectural choices designed for the needs of yesterday, not today
Each of these situations, taken individually, seems manageable. The problem is when they all accumulate together, layer upon layer, over months or years.
How it manifests itself: the signs not to ignore
Technical debt rarely announces itself with a spectacular crash. It usually manifests itself more subtly, through signs that are often misinterpreted as team or process issues.
Development slows down for no apparent reason
If a task that once took a week now takes three—and the team hasn't changed—the problem is almost certainly in the code. Each new feature takes longer and longer because the code is intricate, dependencies are fragile, and every change risks breaking something else.
Bug that multiply
A healthy system has isolated, predictable, and easily located bugs. A system with high technical debt has bugs that recur, bugs that pop up in unexpected places after a seemingly unrelated fix, bugs that no one can reliably reproduce.
Fear of touching the code
When developers hesitate to make changes because "you never know what might break," this is one of the clearest signs of advanced technical debt. Code has become an opaque system that no one truly understands in its entirety.
Onboarding is too slow
How long does it take a new developer to become productive? If the answer is "months," it's not just a skill issue—it's a problem of undocumented code, inconsistent patterns, and a self-explanatory architecture.
Inability to test
A well-structured system is testable. One with high technical debt often isn't: the components are too tightly coupled, side effects are unpredictable, and tests are difficult to write or already exist but no longer work.
How much does it really cost? Some numbers
Technical debt has a quantifiable cost, even if it's often unmeasured. A McKinsey study estimates that, on average, 20-40% of a company's technological value is "hidden" in technical debt—that is, in problems that slow growth and absorb resources without creating value.
In practical terms, consider this scenario: a team of five developers with technical debt draining 30% of their actual productivity. That's 1.5 developers working without producing any net value.
If the average monthly cost per developer is €3,000, you're burning about €4,500 per month—€54,000 per year—in pure inefficiency.
And that's without considering the cost of lost opportunity: undelivered features, extended time to market, and customers lost to more agile competitors.
Technical Debt Categories: Not All Debt Is the Same
Not all technical debt is created equal. Understanding the type of debt you have helps you prioritize interventions.
- Deliberate and prudent debt: "We know it, we'll do it quickly now and fix it later." This is the least problematic type, if you keep your promise to fix it.
- Deliberate and reckless debt: "We don't have time for testing." A deliberate choice to skip key steps. This leads to serious problems in the medium term.
- Inadvertent and prudent debt: looking back, we discover that a technical choice wasn't optimal—but we didn't know that at the time. This is normal in the evolution of any system.
- Inadvertent and reckless debt: The team is unaware of accumulating debt because they lack the skills or vision to recognize it. This is the most dangerous type.
Most systems have a mix of all four. The key is knowing how to distinguish them and manage them with different priorities.
How to manage it?
Technical debt can't be eliminated overnight. But it can be managed systematically, preventing it from growing beyond sustainability.
You can't manage what you can't measure. Tools like SonarQube, CodeClimate, or simple cyclomatic complexity metrics allow you to quantify existing debt and monitor its performance over time. Having concrete data transforms a vague discussion into a conversation about priorities and investments.
One of the most effective best practices is to set aside a
fixed percentage of team capacity—typically 15–20%—for reducing technical debt. Not as an "when-there-is-time" activity, but as a structural part of planning. If it's not in the plan, it won't happen.
Every time you work on a part of the code, you leave it in better condition than you found it. You don't add debt, and the existing one is progressively reduced. It's a simple principle, but when applied systematically, it produces significant results over time.
Continuous refactoring vs. dedicated sprints
There are two schools of thought: integrating
refactoring into the normal workflow (continuous refactoring) or dedicating specific sprints to debt reduction. In practice, the right answer depends on the level of debt and business needs. A hybrid approach often works: continuous refactoring for new debt, dedicated sprints for the most complex critical issues.
When the debt is too much: the border with rebuilding
There's a point beyond which managing technical debt through refactoring becomes inefficient. When the underlying architecture is compromised, when technologies are obsolete and unsupported, when the cost of each change exceeds its value—at that point, the conversation shifts from technical debt to rebuilding.
How do you know if you've reached that point? Some helpful questions:
- Does the team spend more time navigating existing code than writing new code?
- Does every new feature require changes to unrelated parts of the system?
- Are there parts of the system that no one dares touch?
If the answers are overwhelmingly "yes," it's time to consider a more radical option.
The value of an outside eye
One of the difficulties of technical debt is that those who work with it on a daily basis tend to adapt to it, normalizing inefficiencies that an outside observer would immediately perceive as problematic.
A partner like Huulke can bring the outside perspective that's often missing: objectively analyzing the code's status, quantifying existing debt, identifying critical areas, and defining a realistic management plan—one that's compatible with the available
budget and the business's operational needs.
This isn't a judgment on the work done to date. Technical debt is a natural part of any system that evolves over time. It's about understanding where you are, where you want to go, and the smartest path to get there.
If you feel like your system is starting to weigh you down more than it can handle, reach out to us. We'll analyze the situation together and develop a concrete plan.
