What Is Technical Debt Anyway?

Technical debt has been on my mind a bunch the last few weeks. The system I’m working on has been around for a few years. It works, and it works successfully. However, since Day 1 we’ve learned a lot about what we want the system to do, what we don’t want it to do, and the environment it will be operating in. Some of those things fit into the original design, some didn’t.

According to Ward Cunnigham, who coined the term, technical debt is not building something you know is wrong, with the intent of fixing later. You always build things the best way you can, given what you know at the time. Technical Debt happens when you learn something new. Instead of refactoring the code to make it match the new knowledge you make the minimal change to the code to get the right answer, usually in the interest of time.

Two things to keep in mind here. First, when he coined the term, Ward was talking to financial analysts. People who were extremely familiar with the concept of debt and taking on debt to meet a short term need. They also understood the imperative of paying off that debt and the fact that if you didn’t pay off the debt you would eventually go bankrupt. They understood the context. That you can’t just keep increasing your debt and expect there to be no consequences.

Second, technical debt is NOT doing things badly, worse than you could, ignoring your principles and patterns, with the idea that you’ll do it right later. It’s not building a big ball of mud, without clearly separating your domains. It’s not hard-coding your strings everywhere because it’s easier or using exception handling for standard flow control. That’s just bad design and something that we should avoid.

Rather, Technical Debt is choosing to not refactor when you learn something new. You avoid going into “technical debt” by doing whatever refactoring is needed to ensure that that code models what you know about the system/domain. Doing anything else is considered tech debt. Once you have some tech debt you have to pay interest on it. That interest comes in the form of overhead, making it more difficult to make the next change when you learn something else. Eventually you end up in a situation where it’s almost impossible to make the change because the interest on the debt is so high.

There’s a nuance there that needs to be called out. Technical debt is not what happens when you do the wrong thing. It’s what happens when don’t do the right thing. It’s what happens when you’re doing the best you can, learn something new, and then don’t incorporate it.

There’s a time to take on debt. Just like a business, sometimes you take on debt to do something new. To open a store, take on a new line of merchandise, or just run a new advertising campaign. You take on the debt, see the benefit, then pay off the debt.

Whatever you do, don’t use technical debt as an excuse to do less than the best you know how to do.