The LedgerBusiness Dog · $BUSINESS · it's just business
📘 The Ledger

The Debt You Can't See: Technical Debt, Emotional Debt, and the Arithmetic of Deferral

Ward Cunningham invented the most useful financial metaphor in software and then spent seventeen years watching people get it backwards. What he actually meant is far stranger — and it explains your life, not just your codebase.

CowDog12 min readShare on X →

There is a light on the dashboard of my car that has been on for eleven months.

I know what it is. It's not serious — a sensor, a hundred and forty dollars, an afternoon. I have known this for eleven months. And every single time I get in that car, some small quantity of my attention goes to that light, notes that it is still there, files a fresh copy of the same decision not to deal with it, and moves on. Eleven months of that. Call it four seconds a trip, twice a day.

That's roughly eight hours. I have spent an entire working day not fixing a thing that takes an afternoon, and I have paid for it in the world's least useful currency: four seconds at a time, in a form so granular that no individual instance was ever worth acting on.

That's not procrastination. Procrastination is a mood. This is a loan, and I have been servicing it.

What Cunningham actually said

In 1992, Ward Cunningham filed an experience report at OOPSLA about a financial product called the WyCash Portfolio Management System. Buried in it is the passage that gave software its most durable metaphor:

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. Objects make the cost of this transaction tolerable. 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, 'The WyCash Portfolio Management System', OOPSLA 1992

Read that again, because there is a word missing from it, and the missing word is the entire point.

He never says the code is bad.

He says not-quite-right. He says first time. The metaphor spread across the industry anyway as a polite euphemism for garbage — we took on some tech debt meaning we shipped something we're embarrassed by — and it spread so thoroughly that seventeen years later Cunningham sat down in front of a camera to explain that this was not what he had meant at all.

I'm never in favor of writing code poorly but I am in favor writing code to reflect your current understanding of a problem even if that understanding is partial.

Ward Cunningham, 'Debt Metaphor' (2009)

That is a completely different idea, and a much harder one.

The debt is not created by carelessness. It is created by the passage of understanding. You build something that faithfully represents what you knew in March. In September you know more — because you built the thing, and building it is how you found out. The September knowledge and the March artifact no longer agree. That disagreement is the debt, and it exists whether or not anyone did anything wrong.

Which means you cannot avoid it by being good. The only people carrying no technical debt are people who either never shipped anything, or never learned anything after they did.

The distinction that makes the metaphor work

A mistake is a one-time cost. You pay it, it's over, it doesn't recur.

A debt has an interest rate. You pay a small amount, repeatedly, for as long as you hold it — and the payments are individually too small to justify the effort of clearing the principal. That asymmetry is the whole trap. Nothing that costs four seconds ever feels like it's worth an afternoon.

The invisibility is the problem, not the amount

Here's what makes this debt genuinely dangerous rather than merely annoying: there is no statement.

A mortgage sends you a document every month with a number on it. It tells you the principal, the interest, the remaining term. You may hate the number, but you cannot claim not to know it, and that visibility is doing enormous work — it's what allows you to make a rational decision about whether to refinance, overpay, or sell.

Technical debt sends nothing. Neither does the emotional kind. The cost arrives distributed across a thousand moments so small that no accounting system a human runs will ever aggregate them, which is precisely why the thing you don't track quietly stops existing as far as your decision-making is concerned.

McKinsey surveyed 50 CIOs at financial-services and technology companies with revenues above $1 billion — people with genuine visibility into large budgets — and asked them to estimate it. The results are a portrait of a liability everyone can feel and nobody has costed:

20–40%
of the entire technology estate
CIOs' own estimate of tech debt, before depreciation
10–20%
of new-product budget
silently diverted to servicing it
60%
of CIOs
said their tech debt had risen perceptibly in three years

And then the number that turns this from a finding into an indictment: those same CIOs generally allocate less than 20% of their technology budget to paying it down.

Sit with the arithmetic. A liability estimated at up to 40% of the asset base. A recurring interest charge — McKinsey's own exhibit puts most companies above 10% on projects — that comes out of the budget line labelled new products, so it is invisible twice: once as a debt nobody booked, and again as a cost misfiled as innovation. And a repayment rate set below the level at which the principal could ever fall.

That's not incompetence. Every one of those CIOs could explain the problem fluently. It's what happens to any liability that no system forces you to look at.

The part where this stops being about software

I want to be careful here, because extending an engineering metaphor to human life is exactly the move that produces the worst writing on the internet, and this publication is not above the temptation. So let me be precise about what does and doesn't transfer.

What transfers is the structure, not the sentiment. This desk has argued before that double-entry bookkeeping is a usable theory of the self; this is the same argument applied to the liability side, which is the half people skip.

You built a life that faithfully reflected your understanding of yourself at twenty-six. The commute you accepted, the role you optimized for, the way you handle conflict, the friendship you maintain on the terms it had in 2019. All of it was a reasonable encoding of what you knew at the time.

Then you learned more. Not through introspection — through shipping. You found out what the job actually costs by doing it, what the relationship actually needs by being in it. The understanding updated. The artifact did not.

And now every day you spend inside a structure built from an obsolete understanding costs you something small: a little friction, a workaround, a conversation you route around, four seconds of attention at the dashboard light. Every one of those is interest. None of them is ever large enough to force the refactor.

What doesn't transfer

Cunningham's metaphor includes a lender, a term, and the option to declare bankruptcy. Human deferral has none of those cleanly — there is no counterparty, no maturity date, and no court that will discharge an unhad conversation.

The absence of a due date is the part that should worry you. A mortgage ends whether or not you engage with it. This doesn't. Left alone, it does not resolve; it simply accrues until the interest payment is the whole day.

The turn is this, and it's the reason I find Cunningham's actual meaning so much more useful than the popular misreading.

If debt is created by learning, then carrying some is the correct state. A person with zero deferred maintenance on their life is not admirably efficient — they have either stopped updating their understanding, or they are spending so much time refactoring that they never ship anything. Both are worse failures than a dashboard light.

The goal was never zero. The goal is knowing the balance, which almost nobody does, because the whole category is designed to be unfelt. And it decays on its own schedule regardless of whether you're watching — the same quiet arithmetic that governs everything else you own that is getting worse while you're not looking.

Making an invisible balance visible

The practice is not "fix everything." That's the advice that makes people close the tab. The practice is to force the debt onto a surface where it can be decided about, because an unlisted liability cannot lose a fair fight — it can only win by default.

  1. 1

    Write the list, badly, in ten minutes

    Every deferred thing you can think of — the light, the conversation, the appointment, the file structure, the subscription. Don't sort or estimate. The single largest gain here is moving items from ambient dread to text, and it's available in one sitting. Most people find between fifteen and forty items and are startled by the count, because they had been carrying it as one undifferentiated feeling.

  2. 2

    Price the interest, not the fix

    For each item, don't ask what clearing it costs. Ask what holding it costs per week. The dashboard light is four seconds twice a day. The unhad conversation might be twenty minutes of rehearsal every time you see the person. This inverts the whole calculation: things that look cheap to hold turn out to be the expensive ones, which is exactly the information the tiny-payment structure hides.

  3. 3

    Find the compounding ones

    Some debts have a flat rate. Others compound — they make the next thing harder, which generates more debt. An unhad conversation that causes you to route around a person compounds; a dashboard light doesn't. Organisations do this at scale, which is roughly how a forty-minute meeting ends up existing to distribute a decision made in a hallway — the workaround calcifies into the process. Clear compounding debt first even when it's expensive, and be ruthless about the distinction. Everything about this mirrors ordinary bookkeeping, and if you've never set up the twenty-minute version for money, the muscle is the same one.

  4. 4

    Refinance what you can't repay

    Some debt shouldn't be paid off; it should be restructured. You can't fix a role you've outgrown in an afternoon, but you can renegotiate one term of it. Partial payment on a large principal beats another year of full interest, and the perfectionism that insists on the complete fix is often just the deferral wearing better clothes.

  5. 5

    Put one repayment slot on the calendar and defend it

    McKinsey's CIOs knew the number and still allocated under 20% to it, because paydown competes against new work and always loses on urgency. It will lose for you too unless it occupies time that already exists. One recurring slot, small, protected — the point is the rate, not the size, and a rate above zero is categorically different from intention.

Isn't 'technical debt' just a fancy excuse for shipping bad work?

It became one, which is why Cunningham went on camera in 2009 to take it back. The euphemistic usage — we took on some tech debt meaning we knowingly shipped something poor — is a real and widespread abuse of the term, and if that's what someone means, the honest word is available and it's "rushed." His actual claim is narrower and doesn't excuse anything: code that reflects a genuinely partial understanding is not poor work, it's the only kind of work available before you've learned the thing.

Isn't applying an engineering metaphor to your emotional life exactly the kind of thing this publication makes fun of?

Fair, and it's the objection I'd raise first. The failure mode is real: metaphors imported from finance into feelings usually smuggle in a false precision, and "emotional debt" can absolutely become a way of sounding rigorous about vibes. The defense is that I'm importing one specific structural feature — a recurring small cost with no statement — and not the rest of the apparatus. The callout above says plainly which parts don't transfer. If you take only the interest-rate idea and discard the vocabulary, the piece has done its job.

If debt is unavoidable, why does any of this matter?

Because unavoidable is not the same as unmanaged. Interest rates are unavoidable too; that's why people compare them. The claim isn't that you should carry none — it's that the tiny-increment payment structure means you will systematically under-invest in repayment relative to what you'd choose if you could see the total, and the fix is visibility rather than virtue.

How is this different from a to-do list?

A to-do list is sorted by what you intend to do. A debt ledger is sorted by what holding each item costs you per week, which produces a materially different order — and frequently reveals that the thing at the bottom of the to-do list for two years is the most expensive item you own. The reordering is the entire value.

The light

I fixed the sensor. It took an afternoon and a hundred and forty dollars, exactly as forecast eleven months earlier, and the specific pleasure of getting into that car afterward was out of all proportion to a hundred and forty dollars.

Not because the light was important. Because I had been paying for it twice a day in a currency so small I'd never once counted it, and clearing the principal returned four seconds that I had genuinely stopped noticing were being withdrawn.

That's the whole thing. Not that you should have no debt — Cunningham's actual point is that debt is what learning looks like from the outside, and a life with none is a life that stopped updating. It's that there is a balance, it is real, it is currently unlisted, and you are servicing it right now in increments of four seconds while reading a sentence about a car you have never seen.

Go write the list. Ten minutes, badly. You already know most of what goes on it — that's why the light was never the problem.

It's just business.

Sources

  1. Ward Cunningham — 'The WyCash Portfolio Management System', OOPSLA 1992 experience report
    How this was checked

    The original technical-debt passage: 'Shipping first time code is like going into debt… Every minute spent on not-quite-right code counts as interest on that debt.'

  2. Ward Cunningham — 'Debt Metaphor' (2009), transcript
    How this was checked

    His own clarification: 'I'm never in favor of writing code poorly but I am in favor writing code to reflect your current understanding of a problem even if that understanding is partial.'

  3. McKinsey Digital — 'Tech debt: Reclaiming tech equity' (6 October 2020)
    How this was checked

    Survey of 50 CIOs at financial-services and technology companies above $1bn revenue: tech debt at 20–40% of the technology estate before depreciation; 10–20% of new-product budget diverted; 60% reported perceptible growth over three years; under 20% of budget allocated to paydown.

  4. Martin Fowler — 'Technical Debt'
    How this was checked

    Fowler's framing of the concept as 'cruft — deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system'.

Keep reading

This article is educational and satirical content from Business Dog. It is not financial, legal, or tax advice. It's just business.