Using Technical Debt to Your Advantage

Technical debt is like development work we owe to a project. It’s the development equivalent of using a book to prop up a table with a missing foot, or putting a bucket under the leak in the ceiling, or buying cheap sunglasses even when we know they won’t last as long as the more expensive ones. One of the most famous examples of technical debt was the “Y2K bug,” where countless computer systems were threatened by a once-helpful programming trick that only worked when the current year started with “19--“. They’re the little compromises and shortcuts that are good enough for the moment but might cause problems down the line, or even become harder to fix the longer they are left alone.

A website or app with a lot of technical debt can be difficult to maintain. It can be the source of urgent problems at inconvenient times, get in the way of new work, and make it hard for new developers to make sense of the project. But that doesn’t mean that we should (or even can) make it our goal to never create technical debt.

Let’s look at three situations where technical debt can be a good idea (at least temporarily).

Technical Debt as a Lifesaver

In an emergency, creating technical debt can save the day. When there’s a leak in your ceiling, the right course of action is to fix the leak, but a bucket helps contain the problem in the meantime. Similarly, when something unexpected breaks on a website or app, it makes sense that a developer might throw together a temporary solution that stabilizes things until the real problem can be investigated and fixed. This technical debt can help keep your website or app live!

Technical Debt as a Compromise

Sometimes we create technical debt because compromising on our code means we don’t have to compromise on our requirements. Propping up a broken table with a book is not an ideal solution, but it’s usually better than not having a table at all. In creating a website, there might be, for example, a bug in Internet Explorer that prevents one of our features from working correctly. We might find that the only way to fix it is by writing some code that is fragile or messy. We don’t want fragile or messy code in our project, but it’s more important to have the feature working, so it makes sense to compromise.

Technical Debt as a Strategy

Technical debt can help us when short-term wins are a bigger priority than the amount of long-term work. Buying the cheap sunglasses instead of investing in a better quality pair might cost you more in the long run, but if saving on glasses means you can afford sunscreen for today’s beach trip, then it can be the smarter choice. For example, you might have some content on your website that you want translated into Spanish, but don’t have time before your site launches to set up a translation solution that will scale to your entire website. You might choose to set up a temporary, separate Spanish page by hand instead. Once a long-term translation solution is in place, that work might go to waste, but it can be worth it if that Spanish page provided a lot of value in the short-term. We can choose to create technical debt now if its gives us benefits that outweigh the cost of addressing it later.

Like any other kind of debt, the key to technical debt is to pay it off in a reasonable amount of time. Preferably, technical debt is something we create with a plan already in place to address it later. If it does snowball out of control, it helps to tackle it a little bit at a time. For a long-running project overrun by accumulated technical debt, sometimes it makes sense to declare bankruptcy and start fresh.