Every software team pays for technical debt, but few can say how much. Without a number, paying it down competes with features on opinion and loses.
This guide defines technical debt, sorts it into the types that cost money in a Java system, and shows how to measure it, price it and reduce it, including the point at which paying it down piecemeal stops working.
Technical debt definition
Ward Cunningham coined the term in 1992: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. ... Every minute spent on not-quite-right code counts as interest on that debt" (OOPSLA 1992 experience report).
In business terms, technical debt is the gap between how a system is built and how it would need to be built to change cheaply today. It has two parts:
- Principal: the one-off effort to close the gap, such as an upgrade, a refactoring or a missing test suite.
- Interest: the extra cost paid on every change, incident and audit while the gap stays open.
Debt is not always a mistake. Martin Fowler's technical debt quadrant sorts it along two axes, deliberate or inadvertent and reckless or prudent. Shipping a known shortcut to meet a launch date, with a plan to fix it, is prudent and deliberate. Learning after a year in production how the design should have looked is prudent and inadvertent, and Fowler argues it is "inevitable for teams that are excellent designers". The debt to worry about is the debt nobody decided to take and nobody tracks.
The aggregate is large. CISQ estimates the accumulated technical debt in US software at about $1.52 trillion, within a total cost of poor software quality of at least $2.41 trillion (CISQ, 2022). In Stripe's survey of developers, 13.5 hours of a 41.1-hour working week went on technical debt (Stripe, The Developer Coefficient).
Types of technical debt
The types differ in how visible they are and how fast the interest grows. In long-lived Java systems, the expensive ones are rarely the messy methods developers complain about.
| Type | What it looks like in a Java system | How the interest shows up |
|---|---|---|
| Code debt | Duplicated logic, thousand-line classes, dead code paths | Slower changes in the affected files |
| Design and architecture debt | Modules that call each other's internals, one schema shared by everything, synchronous call chains | Every change touches several areas and needs several teams |
| Dependency and platform debt | Java 8 or 11, Spring Boot 2.7 or 3.x out of open-source support, javax namespaces, an old WebLogic or JBoss server | Unpatched vulnerabilities, extended support fees, an upgrade that grows every year |
| Test debt | No automated tests around pricing, billing or other critical rules | Fear of change, long manual regression, defects found in production |
| Build and infrastructure debt | Manual deployments, snowflake servers, a build only one person can run | Slow, risky releases and long recovery from failures |
| Knowledge debt | Rules that live only in the code and in one engineer's head | Everything stops when that person is away |
Dependency and platform debt deserves the most attention because it is the only type with a fixed due date. Code debt gets more expensive gradually; a framework leaving support turns into a security problem on a known day.
Technical debt examples from Java systems
- A store on an unsupported framework. An online wine merchant we worked with ran its store and back office on Java 17 and Spring 5.3, which no longer received open-source fixes, with 12 critical and 35 high-severity vulnerabilities in its dependencies. Moving it to a supported Java and Spring stack took about four weeks, without splitting the application (case study).
- Vulnerable libraries that have fixes. Vulnerable versions of Log4j still made up 13% of all Log4j downloads in 2025, four years after Log4Shell, and roughly 95% of vulnerable component downloads had a fixed version available (Sonatype). That is dependency debt in its purest form: the fix exists, the upgrade work has not been done.
- The javax to jakarta rename. A Spring application that stayed on Spring Boot 2.x now carries the Jakarta EE namespace change, the Spring Security 6 configuration changes and two Spring Boot majors in one upgrade.
- Dead code in production. Knight Capital lost more than $460 million in about 45 minutes in 2012 after a deployment reactivated an old, unused code path; our legacy system modernization guide tells the story.
Platform debt has a due date
For Java systems, the support calendar turns dependency debt into a schedule. Every Spring Boot 3.x branch left open-source support on 30 June 2026, and Oracle's extended support for Java 17 ends in September 2029.
Each version a team skips adds to the principal: one minor Spring Boot upgrade is days of work, three majors at once can be months. Our Java end-of-life dates and Spring Boot 4 migration guides list the dates and the upgrade paths.
How to measure technical debt
No single number captures technical debt. Four groups of measures, most of which a team already has, cover it well enough to price and track.
Dependency age and support status
List every runtime, framework and library with its version, the latest version and its end-of-support date. Track the share of components on supported versions and the months until the next support deadline. Most codebases score badly here:
Known vulnerabilities
Count open vulnerabilities by severity from a software composition analysis scan, and track how long a critical one stays open. Separate the ones fixed by a patch release from the ones that need a major upgrade: the second group is platform debt showing up as security risk.
Delivery metrics
Debt slows delivery before anyone measures it in code. DORA's five delivery metrics show it: change lead time ("the amount of time it takes for a change to go from committed to version control to deployed in production"), deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate. A lead time that grows quarter after quarter while the team size stays the same is interest being paid.
Code-level signals
Static analysis gives a code-level view. SonarQube's technical debt ratio is "the ratio between the cost to develop the software and the cost to fix it" (SonarSource). Use it for trends rather than as an absolute figure, and weight it by change frequency: debt in a file nobody touches costs no interest. The hotspots that matter are files that are both complex and changed often, which git log shows in minutes.
The cost of technical debt: a simple model
Technical debt gets budget when it has a yearly cost next to it. The model below prices the interest from four inputs most teams can estimate in a day; the numbers are an example for a team of eight engineers, not a benchmark.
| Interest item | How to estimate it | Example |
|---|---|---|
| Slower changes | Share of engineering time spent working around debt × team hours × hourly cost | 20% × 8 × 1,700 h × €60 = €163,200 |
| Incidents | Incidents a year caused by debt × hours to resolve × hourly cost, plus business impact | 12 × 30 h × €60 = €21,600 |
| Extended support | Paid support for runtimes and frameworks past their free support | Oracle prices Java SE Universal Subscription per employee, from $15 a month in its smallest band |
| Security remediation | Hours spent mitigating vulnerabilities that an upgrade would remove | 200 h × €60 = €12,000 |
Compare the yearly interest with the principal, the estimated effort to remove the debt. If an upgrade costs 16 engineer-weeks (about €38,400 at the same rate) and removes most of €197,000 of yearly interest, it pays back within a quarter. Debt whose principal exceeds several years of interest can wait, unless it has a due date.
How to reduce technical debt without a feature freeze
Feature freezes for "cleanup sprints" rarely survive the next deadline. Paying down debt continuously works better:
- Reserve a fixed share of capacity. Accenture found that leading companies target 15% of IT budgets for keeping technical debt in balance (Accenture). Make it a standing line in every iteration, not a negotiation.
- Upgrade on the vendor's cadence. A minor Spring Boot upgrade every six months is a routine task; skipping two years of them is a project.
- Automate the mechanical part. OpenRewrite recipes handle most of a framework upgrade's import, configuration and API changes, leaving people to review the result and fix what the recipes cannot.
- Add tests before touching a hotspot. Characterization tests around a pricing or billing rule make the refactoring that follows safe.
- Delete dead code. Code that never runs still has to be compiled, scanned and upgraded.
- Stop adding new debt. A dependency bot, a module boundary test and a definition of done that includes tests cost little and keep the principal from growing.
mvn -U org.openrewrite.maven:rewrite-maven-plugin:run \
-Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-spring:RELEASE \
-Drewrite.activeRecipes=org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_5The command above applies OpenRewrite's Spring Boot 3.5 upgrade recipe to a Maven project; the UpgradeSpringBoot_4_0 recipe takes the next step to Spring Boot 4.
When technical debt remediation needs a modernization project
Continuous paydown works while the interest is moderate and the principal fits into a few iterations. These signs mean it no longer does:
- A runtime or framework leaves free support within a year, and the upgrade path crosses more than one major version.
- Critical vulnerabilities stay open because fixing them needs a major upgrade.
- Change lead time has doubled over two years with the same team size.
- More than a third of each iteration goes to unplanned work and workarounds.
- One or two people are the only ones who can change a business-critical module.
- The architecture forces every change through several teams, and modularizing it is a project of its own (our guide on monolith to microservices migration covers that route).
At that point the debt needs its own plan: an inventory, a priced list of the work and an order to do it in. Our application modernization guide covers how to sequence it.
The Application Modernization Sprint starts with a thirty-minute scoping call and a written ballpark within a week. The first iteration maps your Java system's versions, vulnerabilities and support dates, and prices the debt before any upgrade starts.