Every software system accumulates technical debt. The question isn't whether your codebase has it; it's whether you have a clear enough picture of it to make good decisions about when and how to address it. Most engineering teams don't. They have a vague sense that certain parts of the code are problematic, but no structured inventory, no clear priority order, and no language for explaining the business impact to anyone outside the team.
The result is either chronic under-investment in remediation (because no one can make the case for it) or episodic over-investment (emergency rewrites that halt feature work). Both are expensive. The alternative is a deliberate process for assessing what you have, categorizing it, scoring it for business impact, and building a remediation cadence that fits alongside ongoing product development.
What Technical Debt Actually Is
The term was coined by Ward Cunningham in 1992 to describe a specific, intentional trade-off: writing code that's good enough now with the explicit plan to improve it later. The "debt" metaphor is precise: you're borrowing against future engineering capacity to deliver something today, and you'll pay interest in the form of reduced velocity and increased risk until you pay it off.
Martin Fowler's writing on technical debt has become the most widely referenced framework for thinking about it. His technical debt quadrant distinguishes between two axes: reckless vs. prudent, and deliberate vs. inadvertent. Reckless/deliberate debt is "we know this is wrong but ship it anyway." Prudent/deliberate debt is "we could do this right, but given the constraints, a known shortcut makes sense." Reckless/inadvertent debt is the code that was written without knowledge of better patterns. Prudent/inadvertent debt is the code you wrote well at the time, using the best knowledge available, that you'd do differently now.
Technical debt is not inherently a problem. The reckless/inadvertent quadrant is a problem. The prudent/deliberate quadrant is often good engineering. The assessment step is distinguishing between them.
Building a Technical Debt Inventory
Before you can prioritize, you need to know what you have. Most teams work from a mental map: "the payment service is a mess," "the authentication layer is fragile," "the data import job hasn't been touched since 2019." Mental maps are incomplete, inconsistent, and not transferable between team members.
A technical debt inventory is a structured record of known debt items with enough information to evaluate each one. A minimal record includes:
- Location: The specific file, module, service, or subsystem
- Type: What kind of debt (architectural, code quality, security, dependency, test coverage)
- Description: What the problem is, in concrete terms
- Impact: What happens when this debt manifests (increased bug rate, deployment friction, inability to extend)
- Estimated remediation: A rough order-of-magnitude estimate of how long a fix would take
A spreadsheet or a lightweight issue tracker (GitHub Issues, Linear, Jira) works for this. The specific tool matters less than the discipline of recording things in a shared, searchable place. Tooling like SonarQube can automate the detection of code-level debt: cyclomatic complexity, code duplication, dependency freshness, and coverage gaps. Automated detection supplements but doesn't replace the architectural and business-logic debt that requires human judgment to identify.
Photo by RDNE Stock project on Pexels
The Four Categories That Matter Most for Prioritization
Not all technical debt has the same impact. Categorizing debt items before scoring them helps you apply the right prioritization logic.
Architectural debt is the biggest category by impact. This includes decisions about system structure, service boundaries, data models, and integration patterns that are now inconsistent with how the system needs to work. Architectural debt is typically expensive to remediate and has the highest compounding effect: it makes every other category of debt harder to address and slows down every new feature in the affected area.
Code quality debt includes inconsistent patterns, copy-pasted logic, overcomplicated functions, and poor naming. This category is usually the easiest to detect (automated tools catch most of it) and the most gradual in its impact. It rarely causes outages, but it consistently slows down development and increases the cognitive load required to work in the affected codebase.
Security debt is code that introduces vulnerabilities: outdated dependencies with known CVEs, improper input validation, weak authentication logic, or missing access controls. The OWASP top ten provides a framework for categorizing security debt. This category has a specific urgency profile: it may be dormant for years and then suddenly critical when a vulnerability is exploited.
Dependency debt is outdated libraries, frameworks, or infrastructure components that are no longer maintained or are significantly behind current versions. This debt compounds quickly, because the further behind a dependency falls, the more expensive a future upgrade becomes. A library three major versions out of date is often a multi-week migration; a library one version behind is a few hours.
Scoring for Business Impact
Once you have an inventory, you need a prioritization framework that can compare debt items across categories and communicate priority in business terms. A simple scoring model that works:
Velocity impact: How much does this debt item slow down development in the affected area? Score 1-5, where 5 is "nearly impossible to work in without touching this debt" and 1 is "marginal friction."
Risk: What's the probability and severity of a failure or incident caused by this debt? Score 1-5, where 5 is "active security vulnerability or known fragility causing production incidents" and 1 is "theoretical problem with no observed failures."
Reach: How many product areas, teams, or users are affected by this debt? Score 1-5, where 5 is "every team touches this" and 1 is "isolated subsystem used by a single workflow."
Remediation cost: How long would it take to fix? Score 1-5 (inverse), where 5 is "less than one sprint" and 1 is "multi-quarter rewrite."
A weighted composite score, velocity (30%) + risk (35%) + reach (20%) + inverse remediation cost (15%), produces a ranked list that reflects both urgency and tractability.
Photo by www.kaboompics.com on Pexels
Communicating Technical Debt to Non-Technical Stakeholders
The most common reason technical debt doesn't get addressed isn't lack of engineering awareness. It's failure to communicate business impact in terms that non-technical stakeholders can evaluate against competing priorities.
"The authentication service has high cyclomatic complexity and poor test coverage" is accurate but not actionable for a product or finance stakeholder. "Adding login functionality for the new enterprise plan will take four weeks instead of two because of problems in the existing authentication code, and the same limitation affects three other features on the roadmap" is the same information in a different framing, and it converts into a prioritization decision.
The translation principles:
- Replace "complexity" with "time to add features"
- Replace "test coverage" with "probability of a production incident when we change this"
- Replace "technical debt" with "the reason these estimates keep coming in higher than expected"
"Technical debt conversations work best when engineering and business leadership use the same vocabulary. Most of the time, the vocabulary gap is the actual problem, not the debt itself." - Dennis Traina, founder of 137Foundry
The Agile Alliance technical practices resources include frameworks for incorporating technical work into product planning cycles. The key mechanism is making debt remediation visible in sprint planning rather than hidden in engineering estimates.
Setting a Realistic Remediation Cadence
Attempting to address all technical debt in a dedicated "rewrite sprint" almost always fails. The rewrite becomes larger than planned, takes longer than expected, and delays product work enough to generate organizational resistance to future debt-focused work.
A more durable approach: allocate a fixed percentage of engineering capacity to debt remediation in every sprint. 20% is a commonly cited target, though the right number depends on how severe the current debt burden is. The fixed allocation prevents debt from being perpetually deprioritized when feature pressure is high, which it always is.
Within the allocated capacity, use your prioritization score to select what to address. Start with items that are high velocity-impact and low remediation cost: the quick wins that reduce development friction and build the team's confidence in the process. Architectural debt, which has the highest impact but the highest cost, is addressed incrementally rather than all at once. Track velocity against your prioritization backlog over time. After a few sprints, the data will show whether your remediation rate is outpacing accumulation, the baseline measure of whether the process is working and defensible to stakeholders who want to see return on the investment.
Photo by Polina Tankilevitch on Pexels
Where to Start
For most teams, the most valuable first step is simply creating the inventory. Spend a half-day having engineers identify and record the debt items they encounter or think about regularly. You don't need a complete picture to start; you need enough of a picture to begin making prioritization decisions with more rigor than gut feel.
Once the inventory exists, apply the scoring model to the top 20-30 items. The ranked list that results is likely to confirm what your engineers already knew intuitively while also surfacing some surprises: items that feel urgent because they're painful but score low on business impact, and items that feel acceptable but score high because of their reach or risk.
The 137Foundry web development team works with clients to assess, document, and build remediation plans for technical debt in production applications. The 137Foundry services hub covers the full range of technical work, from initial debt assessment through systematic remediation alongside ongoing product development. More technical guides for business and engineering teams are available at 137Foundry.
