Critical Concept: Technical Debt

The term Technical Debt is thrown around a lot, but it’s important to understand what it means. And what it doesn’t.

Tech Debt is one of those important metaphors that is used routinely in programming and development. Like all metaphors it only has so much value, and is quite routinely stretched well beyond usefulness.

At its core it’s simple concept. Decisions made now create a liability that will need to be fixed in the future. That liability, the requirement for future updates and corrections, is called Technical Debt.

At some point, this debt will have to be paid off. There is worked owed to the future.

The most important thing to understand is that technical debt is not at all a bad thing.

It’s routinely treated like some sort of disaster to be avoided no matter what. But really we should be treating tech debt the same as a business treats actual debt. Debt is not in itself a bad thing. In fact, it’s a very good thing. Making intelligent choices about sustainable lines of credit is a requirement for success, as it allows a business to cover expansion, new facilities, early operating costs, etc.

The same thing occurs with technical debt. Most often, tech debt is undertaken as a temporary hack or shortcut to get something off the ground as quickly as possible. And a lot of the time, that’s an entirely valid option. The pragmatic approach may well mean that time constraints or the expected lifespan of a project dictate not a lot of time to be spent on flexibility, maintainability or testing. This is especially the case in demo or spike solutions, where they are to investigate or demonstrate the viability of an option. Later, if it is proven viable or necessary, work can be done to bring things into line with quality expectations.

This is essentially paying off technical debt.

Like any metaphor it’s easy to stretch this one. People will write happily about declaring technical bankruptcy (I didn’t say it, I declared it) and loan restructuring and all sorts of things. Most of these things over-complicate what is really a simple idea. Sometimes for delivery now we make choices that need to be sorted out later.

If we don’t pay off that debt, we start to pay interest on it – in the form of code that’s harder to work with and covered in band-aids.

This is not to say that the metaphor doesn’t have nice implications. For example, there is good debt and bad debt, technical or otherwise. A line of credit for production materials is good debt. Putting a Ferrari on your credit card is awesome debt. I mean bad debt. Technical debt can also be reasonable and well considered, or just plain negligent.

Just plain “bad code” is not technical debt, though. In order to qualify it has to be deliberately done as a temporary solution with anticipated consequences.

Technical debt can be managed and resolved the same way as any other. Regular repayments in the form of doing some of the refactoring needed. And just as with financial debt, that should be routine, and factored into the ongoing development budget.

Show your support

Clapping shows how much you appreciated Matt Burgess’s story.