What is Technical Debt?

“The borrower is a slave to the lender” – The Book of Proverbs

It’s going to happen to you. It’s inevitable. You’re going to take on technical debt as you build your product.

In this article, we’re going to cover three important questions that you, as the business or product owner, will need to understand:

  • What is technical debt?
  • What are the different kinds of technical debt?
  • How do you pay it off?

By understanding what technical debt is, and how it works in the life of a project, you will be able to direct your development team on key decisions in  your project’s lifecycle.

What is Technical Debt?

Technical debt is either known or unknown incomplete work done in the past that must be fixed either now or in the future.  Just as with financial debt, technical debt is getting something today in return for paying more for it tomorrow. The currency of technical debt is almost always time, which of course turns into money.

In the case of known technical debt, you make a (hopefully) conscious decision to defer doing something “the best way” or “the right way” in return for getting the work done sooner. I put those terms in quotes because we’ll revisit them later in this article.

In the case of unknown technical debt, you typically discover the incompetence as a part of ongoing work. It’s like someone took out a loan on your company but didn’t bother to tell you. It’s painful.

Regardless of whether it’s known or unknown, the longer you borrow your technical debt, the more it will cost you to pay it off.

What are the Different Kinds of Technical Debt?

Known Technical Debt

Taking on known technical debt is easy. It will come up in casual conversation with your development team. They’ll say things like:

  • “We really SHOULD do it this way, but we can do it this other way if we need to”
  • “If I had more time, I’d probably do this differently”
  • “We don’t really have time to automate X, so we can do X manually for now”
  • “We can push X off, but I think it’s a mistake”
  • “That’s not the best way to do it, but if that’s what you want, that’s what we’ll do”

Any time you hear anything like the above, you need to stop the conversation and immediately ask for the trade-offs. How much more will it cost to do this differently later? Understand, to the degree that you can, how much debt you’re taking on.

Now, notice I mentioned doing things “the best way” above. Anytime you hear this, you should push back on your developers. It’s common for developers to want to engineer something perfectly the first time because that’s how we’re wired. We like order. However, often times “the best way” is subjective and there’s an optimal solution somewhere between a hack and perfection.

Unknown Technical Debt

Unknown technical debt is the worst kind of debt. You have no idea it’s there, and when it surfaces it’s usually at the worst possible time. If you hired people who didn’t know what they were doing, but were able to deliver something that works, unknown debt can go undiscovered for months and even years.

I also consider over-engineered and over-built solutions to be technical debt, because you will have to pay a second time to reduce complexity.

Unknown technical debt usually looks like this:

  • Something takes a lot longer than it should have to get done
  • You’re having to explain a feature or concept over and over. This almost always means that the team lacks clarity on what’s expected. Of course, it can also mean that you’re not being clear, but either way you’re accumulating debt
  • The delivered product feels bumpy and messy when you use it. Bad results almost always indicate flawed work

How Do You Pay It Off?

We’ve talked about what technical debt is, and that can have both known and unknown technical debt in your project.

How do you pay it off?

You’ll pay off technical debt with scheduled and unscheduled payments.

Scheduled Payments

As you’re taking on debt, and making those choices to take the shortcut, it’s best to go ahead and put an item on your backlog to revisit the decision at a later point in time.

Then, as you’re working on your product, schedule some time in each work cycle to pay off some of your debt. This will be really tough to do because there won’t be any tangible user benefit, and the temptation will be to just keep deferring. Remember, though, that the more you defer payment, the more interest accrues.

Think of it like a house or car payment. Take it seriously, and don’t miss a payment.

Unscheduled Payments

As you probably have guessed, unscheduled payments can have a devastating effect on your business. If you find that previously undiscovered mess in the middle of a key feature delivery, it can set you back weeks or even months. If you’ve got any doubt about your project, get someone you trust to review it immediately.

Unscheduled payments are like the letter from the IRS telling you that you owe $50,000.

Just Remember

We covered a really deep concept in this article, but we really only scratched the surface. Here’s what you need to know right for now:

  • Technical debt can be known or unknown
  • The longer you take to pay it off, the more it will cost you, and the interest typically compounds
  • Treat technical debt like a normal part of your development process by making scheduled payments whenever possible

Your Assignment

Look at your product backlog. Do you have a category for technical debt? If not, create a way for you to identify future work related to taking on today’s debt.

As a part of your regular product work cycle, find technical debt items and pay them off.

Ask your team to identify technical debt as they see it, and add those items to the backlog.

By treating your technical debt like financial debt, you’ll create the proper urgency on the team to stay out of the hole.