The term “Technical Debt” has changed quite a lot in general meaning over the years, but one fact remains: it is not a sensible goal to eliminate all Technical Debt, at least when you are truly trying to deliver software incrementally.

Wait… what?!

Fine, I’m being provocative for marketing purposes. Let me clarify:

  • I’m using the term “Technical Debt” as it is commonly understood these days: the accumulation of artifacts (code, documentation, …) that interferes with our ability to deliver the next valuable change.
  • Most projects would benefit from reducing Technical Debt.
  • Technical Debt tends to accumulate if we don’t train ourselves to attend to it.
  • Technical Debt is an unavoidable and normal consequence of delivering software incrementally.

A Problem

The confusion about Technical Debt typically comes from the apparent contradiction between “Technical Debt is unavoidable” and “We should reduce Technical Debt”. This happens when we act as Maximizers. Hilariously, some of this reflects the success of XP: “If this thing we do is good, then why not do it all the time?!” That’s the “X” in XP.

Even so, maximizing everything creates suffering. We often encounter tradeoffs, where two benefits oppose each other and so trying to maximize one hurts the other. We often fail to notice tradeoffs. We often disagree whether two forces are trading off or we can safely maximize one of them.

It’s Complex.

Why This Problem is a Problem

When we assume that we should maximize…

  • “Technical Debt is unavoidable” transforms into “There’s nothing we can do about Technical Debt” becomes “Our current level of Technical Debt is not only fine, not only expected, not only normal, but there’s nothing we can do about it, so let’s just ignore it.”
  • “You (almost certainly) should reduce Technical Debt” becomes “We need to relentlessly push for less Technical Debt” transforms into “We need to push for zero Technical Debt, and any goal less ambitious than that is a moral weakness and doomed to fail.”

I’ve exaggerated for effect, but not by as much as you think.

What Now?!

I claim that these two statements are true at the same time:

  • You almost certainly would profit from reducing Technical Debt.
  • You almost certainly would profit from embracing Technical Debt.

Technical Debt is the price you pay for delivering increments sooner. Eliminating Technical Debt would mean delaying the delivery of features.

Technical Debt compounds so we must agree to reduce it. Without that agreement and a strategy to reduce Technical Debt, the compounding effect would cause it to pile up until it overwhelmed our capacity. Letting Technical Debt grow uncontroled would mean delaying the delivery of new features.

Unfortunately, we don’t know how to measure “the right” amount of Technical Debt for you—at least not directly. As far as I can see, the best we can do involves looking for delays related to delivering features and diagnosing them as “cleaning up too much” or “not cleaning up enough”. We need to adjust our behavior continually. We can’t simply “set it and forget it”. Like I said, it’s Complex.

The (Bigger) Problem Behind “The Problem”

And we’ll probably disagree loudly about whether we’re not cleaning up enough or cleaning up too much. And different people will have different preferences about how much to clean up and when. And different people will have different needs, so optimizing for the individual would create even more conflict for the group. And Survivorship Bias guarantees that some people will assume that whatever they did in the past is the right strategy for this (other) group and this (other) project. And Confirmation Bias guarantees that some well-meaning, caring, opinionated folks will keep coming back to the group with article after article supporting their opinion. And it will probably never stop.

Resolve the Issue By Not Resolving It

This is yet another case where Best Practices thinking is likely to let you down. This is yet another case where there is no solution. If you want to deliver changes incrementally and sooner, then you will need to manage Technical Debt. Forever.

Don’t let it run wild and don’t resolve to eliminate it. Don’t squelch the arguments about it. Indeed, arguing about Technical Debt is the way forward. It’s how we continually adjust. It’s how we decide to clean up a little more here and a little less there. It’s how information flows about whether we’re doing enough or too much.

Of course, you probably prefer to argue more constructively and more harmoniously than you have the opportunity to do now. Your experience of trying to argue about this, whether with co-workers or random strangers on the internet, has likely felt more damaging than helpful. You’re probably afraid, maybe even terrified, of what would happen if you tried to argue openly and freely with your co-workers. It feels so much safer to retreat to Best Practices thinking or to give up on managing Technical Debt altogether. I understand.

Our collective struggle over Technical Debt seems much more to me to have been a clear signal of our collective trust deficit than a signal of our competence as software developers. I think we need to trust each other more to make any meaningful progress here.

What do we do about that? The answer fills bookshelves. One of my favorite places to start is Patrick Lencioni’s The Five Dysfunctions of a Team. If you have a favorite first resource on the topic of increasing trust, then share it with the world!