The Interest Rate on Your Codebase: A Financial Framework for Technical Debt

Technical debt is a deliberate deviation from an optimal design that yields short-term value at the cost of increased future work.

Like financial debt, it has principal (the cost to fix), interest (the ongoing drag), and an interest rate (the frequency with which you interact with the debt multiplied by the friction it causes).

The problem isn't taking on debt – it's failing to manage the interest. This post provides a framework for classifying, measuring, and paying down technical debt at any organizational scale.

In 1992, Ward Cunningham presented an experience report at OOPSLA describing the development of a financial portfolio management system in Smalltalk. He needed to justify ongoing refactoring to his business stakeholders, so he reached for a an unironically relevant metaphor they'd understand¹:

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… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. – Ward Cunningham

Notice what he didn't say. He didn't say "writing bad code is like going into debt." He said shipping code before you fully understand the problem domain is like going into debt. The distinction matters enormously.

Cunningham was describing something specific: the team had built a working system, and through the process of building it, they had learned things about the domain that the code didn't yet reflect. The code worked. It was well-written. But it encoded an earlier, incomplete understanding of the problem. The "debt" was the gap between what the team now understood and what the code expressed.

This is a much more subtle – and much more useful – concept than "the code is messy."

Building on Cunningham's original insight, and drawing from a decade of subsequent refinement by Martin Fowler, Philippe Kruchten, and others, here's the definition I use:

Technical debt is a deliberate or accidental deviation from an optimal design that yields short-term value at the cost of increased future work.

Technical debt is a deliberate or accidental deviation from an optimal design that yields short-term value at the cost of increased future work.

Furthermore, technical debt has four essential properties:

1. It has principal – the cost to remediate or redesign the code to its optimal state
2. It accrues interest – the ongoing drag on velocity, reliability, and developer experience caused by working around the suboptimal design
3. It is context-dependent – what constitutes "optimal design" changes as requirements evolve, scale increases, or the team's understanding deepens
4. It is not inherently bad – like financial debt, it can be a rational tool when used deliberately

That last point is critical. A mortgage isn't reckless. Neither is shipping a prototype with hardcoded configuration to validate a business hypothesis. The question isn't whether to take on debt. It's whether you know you're doing it, and whether you have a plan to service it.

Precision matters here. Conflating these concepts with tech debt dilutes the metaphor to uselessness.

• Bugs aren't tech debt because bugs are liabilities, not loans – you didn't choose them for short-term value. They're defects. Fix them on their own merit.
• Legacy systems aren't tech debt because age \(\neq\) debt. A 15-year-old COBOL system that runs reliably isn't debt if nobody needs to change it. It's legacy – and only becomes debt if it impedes change.
• Missing features aren't tech debt because "we haven't built X yet" isn't a loan you took out. It's product scope. Put it on the backlog.
• "Bad code" isn't tech debt because subjective aesthetics aren't debt unless they cause measurable drag. If the only problem is that you don't like the style, use a linter.
• Missing documentation isn't necessarily tech debt. It's only debt if it increases the cost of future work. Otherwise it's operational risk – might be debt, might not.
• Using an old framework isn't necessarily tech debt. It's only debt if upgrading would reduce future costs enough to justify the remediation. Otherwise it's version lag – assess on a case-by-case basis.

The litmus test: does this thing have both a principal (cost to fix) and an interest rate (ongoing cost of not fixing it)? If it only has a principal and no meaningful interest, it's not debt – it's just cleanup work. If it has interest but no meaningful principal (you can't fix it), it's a constraint, not debt.

graph TB
    subgraph "Is It Really Technical Debt?"
        direction TB
        START["Identified Issue"]
        Q1{"Was it a design choice<br/>(deliberate or inadvertent)?"}
        Q2{"Does it cause ongoing<br/>friction (interest)?"}
        Q3{"Can it be remediated<br/>at a known cost (principal)?"}

        DEBT["✅ Technical Debt<br/>Manage it with the<br/>financial framework"]
        NOTDEBT1["❌ Not Debt<br/>It's a defect — fix it<br/>on its own merit"]
        NOTDEBT2["❌ Not Debt<br/>It's cleanup, not debt service"]
        NOTDEBT3["❌ Not Debt<br/>It's a constraint,<br/>not a financial instrument"]

        START --> Q1
        Q1 -->|"Yes — a tradeoff<br/>was made (knowingly<br/>or not)"| Q2
        Q1 -->|"No — it's a bug<br/>or defect"| NOTDEBT1
        Q2 -->|"Yes — it slows<br/>future work"| Q3
        Q2 -->|"No — it just<br/>looks ugly"| NOTDEBT2
        Q3 -->|"Yes"| DEBT
        Q3 -->|"No — there's no<br/>clear fix"| NOTDEBT3
    end

• Principal is the cost to remediate or redesign. "Refactoring the auth module will take 3 sprints."
• Interest is the ongoing maintenance cost, velocity drag, and incident risk. "Every feature touching auth takes 2x longer and breaks in staging."
• Interest rate is the frequency of change multiplied by the system friction. High for core modules that every team touches, low for rarely-touched utilities.
• Refinancing is a large-scale refactor or migration – moving from a monolith to services, upgrading the ORM. You replace one debt instrument with another that has better terms.
• Bankruptcy is a full system rewrite. "We're throwing it away and starting over." Sometimes necessary, usually avoidable.
• Credit line is the team's tolerance for complexity before velocity collapses. It varies by team size, skill, and tooling – and it's finite.
• Cash flow is engineering capacity: the person-hours available for debt service. It's your sprint capacity minus feature commitments.
• Amortization is gradual debt paydown alongside feature work. "Every PR in auth must leave the code better than it found it."
• Debt-to-equity ratio is the proportion of your codebase that is suboptimal vs. well-designed. High ratios mean fragility; low ratios mean resilience.
• Credit rating is the team's track record of paying down debt. Teams that consistently ship debt paydown earn trust for future borrowing.

A key insight falls out of this mapping:

High-interest debt is debt that compounds every time you touch it.

High-interest debt is debt that compounds every time you touch it. The auth module you hack around daily costs orders of magnitude more than the deployment script you run quarterly – even if the deployment script's remediation cost (principal) is lower. This is why prioritizing debt paydown by "ease of fix" is backwards. You should prioritize by interest rate.

Not all debt is created equal, and not all debt should be treated the same way.

Here are a few high level categories:

Technical debt doesn't appear and disappear in a single event — it follows a lifecycle. The diagram below traces debt from the moment it's incurred through a decision point where teams choose one of five responses. Notice the feedback loops: deferred debt compounds back into accruing interest, and even "resolved" debt eventually gives way to new debt as the system evolves.

graph LR
    INCUR["Debt Incurred<br/>(design shortcut taken)"]
    ACCRUE["Interest Accrues<br/>(ongoing friction)"]
    DETECT["Debt Detected<br/>(pain threshold reached)"]
    ASSESS["Debt Assessed<br/>(principal + interest estimated)"]
    DECIDE{"Decision Point"}
    PAY["Pay Down<br/>(refactor/redesign)"]
    REFINANCE["Refinance<br/>(large migration)"]
    ACCEPT["Accept & Monitor<br/>(interest rate is low enough)"]
    BANKRUPT["Declare Bankruptcy<br/>(full rewrite)"]
    DEFER["Defer<br/>(interest continues)"]

    INCUR --> ACCRUE
    ACCRUE --> DETECT
    DETECT --> ASSESS
    ASSESS --> DECIDE
    DECIDE -->|"High interest,<br/>manageable principal"| PAY
    DECIDE -->|"High interest,<br/>large principal"| REFINANCE
    DECIDE -->|"Low interest"| ACCEPT
    DECIDE -->|"Unmaintainable"| BANKRUPT
    DECIDE -->|"No capacity"| DEFER
    DEFER -->|"Interest compounds"| ACCRUE
    PAY -->|"Debt resolved"| INCUR
    REFINANCE -->|"Lower interest rate"| ACCEPT

It's important to resist the temptation to moralize about technical debt. In many contexts, taking on debt is the right decision:

• Speed to market: A startup with 6 months of runway doesn't need a perfectly designed system. It needs product-market fit. The debt is rational because the alternative is bankruptcy – the real kind.
• Uncertain requirements: When you don't yet know what the system needs to do, investing in a "perfect" architecture is waste. Build the thing, learn what it should have been, then refactor. This is Cunningham's original insight.
• Asymmetric risk: If the upside of shipping fast is 100x and the downside of the debt is 2x, the expected value calculation is trivial.
• Exploration and prototyping: Prototype code should be debt-heavy. That's the point. The mistake is promoting prototype code to production without acknowledging the accumulated debt.

Tech debt is often a sign of rational decision-making under uncertainty – not incompetence.

This is the framing I use with stakeholders, and it changes the conversation immediately. Instead of "we need to clean up the code" (which sounds like an engineering vanity project), it becomes "we need to manage our financial exposure" (which sounds like responsible governance).

Avoid metrics theater. Lines of code, cyclomatic complexity, and lint scores are proxies at best and noise at worst. The following signals are more useful for measuring the interest on your technical debt:

• Change amplification measures how many files or systems must be touched per feature. Track PR size and the number of changed files over time. If the trend is up, interest is compounding.
• Time-to-confidence measures how long before an engineer trusts that a change won't break something. Measure the gap from "code complete" to "merged with confidence." Long gaps mean high friction.
• Error surface area measures the number of ways a change can fail. Count unique failure modes in CI/CD and staging. The more ways things break, the higher the interest.
• Onboarding half-life measures how long it takes a new engineer to become productive. Track days-to-first-meaningful-PR per new hire. If it's getting longer, your codebase is getting harder to understand.
• Fear factor measures which systems nobody wants to touch. Survey your engineers: which parts of the codebase do they avoid? Fear is a leading indicator of high-interest debt.
• Rework rate measures code that is added then quickly modified or deleted. This is DORA's new fifth metric – now officially tracked³.

These signals map directly to interest, not principal. A system with high change amplification and a high fear factor is accruing massive interest, regardless of how "easy" the fix would be.

Interest on technical debt compounds in ways that are genuinely analogous to financial compound interest. Consider a module with a 10% "tax" – every feature touching this module takes 10% longer than it should.

Hacking around debt like trying to kill a mythological hydra – the effort is herculean, but the problem only grows with each swing of the engineer's sword.

In isolation, 10% sounds manageable. But compound it:

• Feature A takes 10% longer because of the debt
• Feature B also touches the module, and also adds workarounds, slightly increasing the friction
• Feature C touches the module and now takes 15% longer because of the accumulated workarounds from A and B
• Feature D's developer, frustrated by the mess, copies the module instead of extending it – creating a new debt instrument
• Features E through Z now have two versions of the module to maintain

This is how a 10% tax becomes a 50% tax in 18 months. I've seen this exact pattern play out at multiple companies. Hacking around debt like trying to kill a mythological hydra – the effort is herculean, but the problem only grows with each swing of the engineer's sword. If the banner image of this blog post reminds you of a terrifying hydra, then I've accomplished my goal of being illustrious.

The chart above models three scenarios over five years. The red line shows what happens when debt is left unmanaged – a 10% velocity tax compounds into a 50%+ tax within a few years. The yellow line shows moderate, consistent debt service. The green line shows aggressive front-loaded paydown that levels off once the worst debt is addressed.

The takeaway: the earlier you start servicing debt, the cheaper it is. Just like a mortgage.

The compounding effect isn't just an analogy – it's a law of software evolution.

Lehman's laws of software evolution, established empirically in the 1970s and validated repeatedly since, state that⁴:

1. Continuing Change: A system must be continually adapted or it becomes progressively less satisfactory
2. Increasing Complexity: As a system evolves, its complexity increases unless work is explicitly done to reduce it
3. Self Regulation: System evolution is a self-regulating process with statistically determinable trends

Law #2 is the kicker. Complexity doesn't increase because engineers are careless. It increases because that's what happens to systems that interact with the real world. Entropy is the default. Order requires energy. This is as true in software as it is in thermodynamics.

Entropy is the default. Order requires energy.

Technical debt, in this framing, is unreduced complexity – the delta between the system's current complexity and the minimum complexity needed to serve its current purpose. Interest is the ongoing cost of carrying that excess complexity. And Lehman tells us that without deliberate effort, that delta only grows.

This is where debt management gets serious, and where I've seen the most damage done. At one growth-stage company I worked with, the engineering team tripled in a year. The codebase they inherited from the startup phase was a classic "clean interfaces, dirty internals" system – which had been fine at 8 engineers. But at 30, the dirty internals became a coordination bottleneck. Three teams would independently hack around the same internal limitation in three different ways, creating three new debt instruments per quarter. The startup-era debt didn't grow linearly with headcount – it grew quadratically, because every new engineer was another node in the collision graph.

You're past the point where everyone knows everything, but not yet at the scale where platform teams and formal governance make sense. This is the most dangerous stage.

At enterprise scale, technical debt becomes systemic risk. Individual modules matter less than system-level friction: API boundaries, deployment pipelines, shared libraries, and the organizational structures that produce them.

Notice how the allocation to debt service increases with company size. This is counterintuitive – you'd think larger companies with more resources could afford less proportional debt spending. But larger companies have more accumulated debt, more system boundaries where debt hides, and higher coordination costs. The 5% a startup spends is "fix it when you see it." The 25% an enterprise spends is "dedicated teams, formal processes, migration projects."

GitClear's 2025 research on AI-assisted code quality found¹¹:

• Code duplication (cloned blocks of 5+ lines) increased 8-fold between 2022 and 2024
• Refactoring activity dropped from 25% of changed lines in 2021 to less than 10% in 2024
• Code churn (code added then quickly modified or deleted) rose steadily, reaching an estimated ~7% by 2025

Google's 2024 DORA report corroborates: teams with higher AI adoption reported faster code review and improved documentation, but the same cohort showed a measurable decrease in delivery stability³.

In financial terms: AI assistants have massively increased the rate at which teams can issue new debt, while simultaneously reducing the rate at which existing debt gets serviced.

The mechanism is straightforward:

1. AI makes it trivially easy to add code – reducing the perceived cost of new functionality
2. AI makes it no easier to understand existing code – the cognitive overhead of working in a complex codebase hasn't changed
3. AI-generated code tends toward the generic and duplicative – it doesn't know your architecture, your conventions, or your existing abstractions
4. Developers using AI skip the "understand before modifying" step more frequently – the code is generated faster than understanding develops

This creates a specific new type of debt that deserves its own name: comprehension debt.

AI assistants have massively increased the rate at which teams can issue new debt, while simultaneously reducing the rate at which existing debt gets serviced.

Comprehension debt is the gap between the size of a codebase and any individual engineer's ability to hold a working mental model of it. Traditional technical debt is about code that's wrong – suboptimal designs that create friction. Comprehension debt is about code that might be individually correct but is collectively unintelligible. Each AI-generated function may work perfectly, but when 40% of the codebase was written by an LLM that doesn't know your team's conventions, the overall architecture drifts toward incoherence – ten different patterns for error handling, six ways to call the same API, three duplicate utility functions that almost-but-do-not-quite do the same thing.

The insidious property of comprehension debt is that it can't be addressed by traditional refactoring. You can't "fix" a codebase that nobody can hold in their head. The debt isn't in any individual module – it's in the aggregate. The principal doesn't show up in any static analysis tool, and the interest manifests as slower onboarding, more bugs from unexpected interactions, and a growing sense among senior engineers that "nobody really knows how this system works anymore."

• Treat AI-generated code as a PR from a junior engineer: review it with the same rigor, question design decisions, check for duplication against existing code. I may change my tune as AI code review tools improve, but I would also resist the urge to have something like CodeRabbit do your PR reviews, especially since this would fail to narrow the comprehension gap
• Maintain strong architectural guard rails: linters, architecture tests (like ArchUnit), import restrictions, and pre-commit hooks that prevent the most common AI-introduced anti-patterns
• Increase refactoring capacity proportionally: if AI is helping you produce code 2x faster, you need 2x the refactoring capacity to prevent the debt ratio from spiking
• Track AI-specific quality metrics: code duplication rate, churn rate, and the ratio of net-new code to refactored code

Conway's Law states that organizations design systems that mirror their own communication structures⁸. The implication for technical debt is profound: organizational friction becomes architectural friction becomes technical debt.

If teams A and B can't communicate efficiently, the interface between their services will accrue debt – duplicated logic, mismatched assumptions, undocumented contracts. The debt isn't caused by poor engineering. It's caused by poor organizational design. And no amount of refactoring will fix it, because the structure that created the debt will recreate it.

The Inverse Conway Maneuver – deliberately restructuring teams to match the desired architecture – is the only way to address this class of debt. It's also politically difficult, which is why this debt tends to persist.

Technical debt grows fastest in organizations with these incentive patterns:

Tech debt grows fastest where engineers feel powerless to address it. If your process doesn't allocate time for debt service, debt will accumulate. This is not a technical problem. It's a governance problem.

The most pernicious version of this: organizations that say they value quality but measure only velocity. Engineers quickly learn which metric actually matters, and they optimize accordingly.

You can't manage what you can't see. Build a simple inventory:

Don't over-engineer this. A spreadsheet or a markdown file (or org-mode file if you're cool like me 🤪) in the repo is fine. The point is visibility, not process.

Sort your inventory by interest rate, not by principal. The debt that every team interacts with daily costs more than the debt that one team encounters quarterly, even if the quarterly debt has a higher remediation cost.

The formula is simple:

\[ \text{Debt Priority Score} = \text{Interest Rate} \times \text{Number of Affected Teams} \times \text{Interaction Frequency} \]

This isn't meant to be precise – it's meant to force the right conversation.

Decide on a fixed percentage of engineering capacity for debt service. This should be:

• Non-negotiable: it doesn't get borrowed for feature work when deadlines loom. The moment debt service becomes "optional," it stops happening – the same way savings stop when they're "whatever's left after spending." Treat it like a payroll obligation, not a discretionary budget.
• Visible: leadership should see how the capacity is being used. A monthly one-pager showing which debt was serviced, what metrics improved, and what's next builds institutional trust. Over time, this evidence base is what lets you increase the allocation when it's needed.
• Measured: track whether debt service is actually reducing interest payments. If you allocated 20% to debt service last quarter and velocity didn't improve, either you're paying down the wrong debt or the measurement window is too short.

In practice, I've seen this work best when the allocation is protected at the team level, not the org level. Telling 50 teams "the org is allocating 20% to debt" is meaningless. Telling each team "20% of your sprints go to debt service, and here's how we'll track the impact" creates accountability.

For each debt paydown initiative, define:

1. What metric improves? (Change amplification decreases, onboarding time drops, incident rate falls)
2. By how much? (Even a rough target helps)
3. By when? (Timeboxed – if it's not showing results in 2-3 sprints, reassess)

Track these before and after. This builds the institutional evidence base for continued debt service investment.

Here's a concrete example: suppose you're refactoring the authentication module. Before starting, measure: average PR size for auth-touching features (say, 15 files), average time from "code complete" to "merged" (say, 4 days), and staging failure rate for auth changes (say, 25%). Set targets: reduce PR size to <8 files, merge time to <2 days, staging failures to <10%. After two sprints of focused refactoring, measure again. If the metrics moved, you have evidence. If they didn't, you're either fixing the wrong thing or the refactor isn't done yet.

Paydown without prevention is a treadmill. Implement:

• ADRs for deliberate debt decisions – every time the team knowingly takes on debt, write a one-page record: what shortcut was taken, why, what the expected interest rate is, and what conditions should trigger paydown. This is the difference between a mortgage (documented, scheduled) and credit card debt (invisible, compounding).
• Code review standards that explicitly evaluate debt introduction – add "does this PR introduce or increase technical debt?" as a standard review question. If yes, require a comment explaining the tradeoff.
• Architecture tests that prevent structural regression – tools like ArchUnit (Java), Dependency Cruiser (JavaScript), or even simple import-graph checks in CI can enforce "module A should not depend on module B" constraints. These automated guardrails catch drift before it compounds.
• Post-incident reviews that trace root causes back to specific debt – when an incident occurs, ask: "Was known technical debt a contributing factor?" If the answer is yes three times for the same debt item, it gets promoted to the top of the priority list regardless of its planned schedule.