Translating Technical Debt

What technical debt actually means, and how to explain it to someone who doesn't write code

An engineer asks for two sprints to "pay down technical debt," and the person who owns the budget hears two sprints with nothing to show for them. The phrase was invented to make exactly this conversation easier, and a lot of the time it now gets in the way.

The fix is not a better slide. It's going back to what the metaphor meant in the first place, because the original version already contains the answer to the question the business side is really asking: is this worth paying for?

Where the phrase came from

Ward Cunningham coined it in 1992, in a short experience report for the OOPSLA conference about WyCash, a portfolio management system his team built. The line most people know is "Shipping first time code is like going into debt." The same paragraph says a little debt speeds development, as long as it is paid back promptly with a rewrite, and that the danger is debt that never gets repaid.

In a later video (the transcript is on the c2 wiki) Cunningham explained why he reached for a money metaphor at all. WyCash was financial software, and he needed to explain to his boss why the team kept reworking code that already worked. As the team learned how the financial objects really behaved, they changed the program to match that understanding. If they had not, he said, they would keep stumbling over the gap between what the code said and what they now knew, and that stumbling would slow them down the way interest slows down a loan.

So the original idea is simple. You ship before you fully understand the problem, because shipping is how you learn. Then you put what you learned back into the code. Skip that second step for long enough and every change gets slower.

What it does not mean

In the same video, Cunningham said many people had confused the metaphor with the idea of writing code badly on purpose and cleaning it up later. He was clear that he never favored writing code poorly. What he favored was code that reflects your current understanding, even when that understanding is partial, written cleanly enough that you can change it once you know more.

That matters for the conversation. When an engineer says "we have technical debt," the business side often hears "we cut corners" or "we did it wrong." Usually it means something closer to "we know more now than we did when we built this, and the code has not caught up." That is not a failure. It is what learning looks like in software.

Principal and interest, in plain terms

Martin Fowler's explanation on his site is the clearest one I know of, because it uses the two parts of a loan that everyone already understands.

• The principal is the cost of cleaning the code up.
• The interest is the extra effort every new change costs while the mess is still there.

His example: a confusing structure means a new feature takes six days instead of the four it would take with a clean structure. Those two extra days are the interest. Cleaning up the structure would take five days.

If that is the only feature coming, cleaning up is a bad deal. Fowler points out you would spend nine days instead of six. But if two more similar features are on the way, cleaning up first makes the team faster overall. Using his numbers: three features without the cleanup is 18 days, and the cleanup plus three faster features is 5 + 12 = 17 days.

Look at what that decision depends on. Not on how ugly the code is, but on how much more work is coming through that part of the system. Engineers know the interest rate. The business side knows the roadmap. Neither can make the call alone.

Not all debt is the same kind

Fowler also sorts debt into a simple grid. One axis is whether the debt was deliberate (you knew you were taking a shortcut) or inadvertent (you found out later). The other is whether it was prudent (taken on with the cost weighed against the benefit) or reckless (taken on without weighing anything).

In plain terms:

• Deliberate and prudent: "We took a shortcut to hit the launch date, and we knew it would cost us later." This is a business decision that worked as intended. The bill is now due.
• Inadvertent and prudent: "Now that we have built it, we understand how it should have been built." Fowler says even the best teams end up here, because you learn as you go. This is Cunningham's original meaning.
• Deliberate and reckless: "We knew better and skipped it anyway to go faster." This usually comes from underestimating how soon the shortcut would start costing time.
• Inadvertent and reckless: "We didn't know what good looked like." This is a skills conversation, not a debt conversation.

Fowler's point is that the useful question is not whether a team has debt, since every team does, but whether it was prudent or reckless. Knowing which kind you are talking about tells you whether this is a normal bill, a lesson, or a problem with how the work is done.

If you write the code: how to explain it

The goal is to give the person with the budget something they can decide on. A few habits help.

1. Lead with the interest, not the principal. "We need two sprints to refactor billing" is a cost with no benefit attached. "Every change to billing takes about two extra days because of how it is structured" is a cost they are already paying. Use your own real numbers, even rough ones.
2. Connect it to work that is actually coming. Name the upcoming items on the roadmap that go through that part of the system. If nothing is coming, say so. Leaving it alone can be the right call, and saying that out loud earns you trust for the times it is not.
3. Show the payback. Cleanup cost, the time each change saves, and how many changes until it pays for itself. Fowler's example is a good template because the arithmetic fits on one line.
4. Say which kind it is. "We took this shortcut on purpose to make the March launch" lands very differently from "this is how we learned the problem." Both are fine. Just say which.
5. Ask for a decision. End with the options and what you would pick: pay it now, pay it before a specific feature, or leave it. Do not end with "let's discuss."

If you fund the work: how to ask about it

Business leaders can make this conversation easier too.

• Ask "what does this slow down, and by how much?" instead of "why is the code bad?" The first question gets you an interest rate. The second gets you a defensive answer.
• Ask "what happens if we never pay it?" Sometimes the honest answer is "nothing much, that area rarely changes," and that is useful to know.
• Share what is coming. The engineers can only work out whether the cleanup pays back if they know what the next few months of work look like.
• Treat a debt request as information, not an admission. The team is telling you about a cost you are already paying.

One question that carries most of it

Every version of this conversation comes down to one question both sides can answer together, what is the interest on the work we are about to do? Explaining tradeoffs in terms like that, so the decision happens in the meeting, is what TranslateTech's Geek2Speak series is about.

Next time technical debt comes up, ask (or answer) that one question before anyone talks about how long the cleanup takes.