I’ve spoken to some leaders at some organizations lately and I’ve been hearing a common lament. Somewhere in discussing their architecture or processes, they look down, shake their head a bit and say something like “Well, we have technical debt,” before considering what solutions are available to them.

Thinking about rework that may be needed in your software and processes before introducing new features is a good idea, but the metaphor of technical debt like financial debt can cause some problems.

Thinking of technical debt like actual, financial debt may make sense on the surface. They’re both “debt,” right?

The problem is there are a lot of false assumptions that can get carried over when thinking of technical improvements you’d like to make as “debt”

Why’s that?

Some traits of financial debt:

1. All debt gets paid off
2. Debt has interest rates, making it easily measured and payoff predictable. (Because its interest rate is part of the debt agreement)
3. You can borrow as long as your credit score holds up
4. Debt that you ignore will grow
5. Debt can be used to buy things
6. You can declare bankruptcy

Do you see the problem here? Carrying around this metaphor often means subscribing to these ideas, many of which aren’t true as it applies to technical problems and solutions and rework.

Let’s tackle the biggest fallacy that results from carrying around this metaphor: That debt must be paid off.

This simply isn’t true. Not every slightly imperfect design decision or code created needs to be revisited and returned to a perfect state or otherwise reworked. Perhaps the bit of code is not read often and runs well. Perhaps it changes rarely.

The opposite can also be true, something small can cause your team to spend a lot of time on it, either through running, patching, or understanding.

Calling all bits of your codebase or process that may need rework “technical debt” can also encourage one to engage in point 3; continuing to borrow, a “put it on my tab” mentality, where once you have debt, it can be even harder to be aware of the problems caused by adding more.

Some of these traits do overlap, you can ignore code or make design decisions that will cause rework later in exchange for shipping. This is sort of “buying” something using your “debt” but the price isn’t very clear, making this a potentially difficult trade off to evaluate well.

You also have the ability to declare bankruptcy. You could just say “we’re over it, we’re doing a full rewrite,” which somewhat frees you from the previous debt, but also places a burden on you to build something new. You’re not resetting to zero, you’re actually going negative.

Am I saying don’t “pay off” any “technical debt” or that you can never do a rewrite? No, of course not. I’m saying that thinking of it like debt at all, as something you “have to” or “should” pay off without thinking further on it and being more intentional is suboptimal which can keep you from missing the point.

This doesn’t mean you can’t use the metaphor or need to remove it from your vocabulary. But instead, that there can be benefit from considering and conceptualizing the problem a bit more directly, as a burden, instead of an often rarely measured, poorly defined pool that you can continue to dump things into.

• “How much human intervention will be needed because of this [change, thing, whatever]?”
  • This helps filter out what is just technically perfect, e.g. an older technique framework, etc.. from what will actually cause someone to have to respond, repair, or otherwise react.
• “Does this keep us from improving elsewhere?”
• “Am I concerned about something concrete or is this premature optimization?”
• “Are many people going to get tripped up here and/or sink a lot of time because of this?”

Do you disagree, have you found the financial metaphor helpful? Are you “paying off” the debt for the sake of it? What is your experience in balancing shipping vs rework? Shoot me an email