Michal Charemza

I generally avoid referring to anything as technical debt. While not an entirely meaningless term, I suspect that in almost all contexts there are better things to say. In this post I argue why I think the term shouldn't be used, and what should be said instead.

It means too many things

I've heard the term technical debt being used for:

• Bugs that exist right now
• Properties that risk introducing bugs with future development
• Properties that risk slowing future development
• Not having some form of quality assurance or tests
• Not using a consistent architecture
• Limits of scalability of a system in terms of users/usage
• Things that mean security isn't as tight as it could be
• Things that mean performance/efficiency isn't as good as it could be
• Even just regular not-implemented user-facing features

Putting all this together "technical debt" means virtually any property of a system that can be improved in any way! It's far too vague to have meaningful conversations about it in general.

It sounds absolute

The debt metaphor makes it sound absolute: for a financial debt, who can argue that it exists and it has to be dealt with. But this is engineering dealing with humans, trade-offs and risks, all of which can change over time when situations evolve or when information is revealed, and so very much not absolute.

You may never feel the effects of the debt

Even if limiting to what I think are the most typical definitions — properties of code that slow development or risk more bugs when code is changed — it would only involve a subset of all possible changes. If the need for those changes doesn't arise then you never realise the effect of the so-called debt. This is where the debt metaphor really breaks down: other than by taking drastic actions, most of us can't escape the consequences of financial debt, but this is not true for technical debt.

It can lead to wishful thinking

I think because the term debt sounds like it will be addressed, it can lead to wishful thinking, which itself leads to affecting decisions on what you do today. Veering slightly from the point of this post into avoiding "technical debt", I very rarely make a change that is contingent on a future task in order to be acceptable.

The term can sound so negative it can lead to over-engineering

On the other hand, I suspect sometimes technical debt sounds so negative, the avoidance of it can lead to over-engineering solutions, rather than considering the fact that if something is needed later, it often can and should be done later.

It's not obviously linked to real-world consequences

From what I know the term was coined to communicate technical concepts to non-technical people. But because the term is so vague, and I think still sounds quite technical, I think this ironically makes it harder to convince that things labelled (just) as "technical debt" have real-world consequences and so should be avoided or addressed.

It can suggest an ideal architecture independent of constraints

If you don't have the resources — for example time/knowledge/money — to make an architecture, then it's clearly not the perfect architecture for the situation at hand. If it can't exist, it's not ideal in any meaningful sense, so labelling non-achievement of such an architecture as "technical debt" can be a waste of words, time, or even emotions.

What to say instead?

Say the thing: bug, scalability limitation, performance issue (ideally with at least rough numbers), security issue (stating how severe or how it would be exploited), development productivity issue (around what specific classes of features), missing user-facing feature, lack of quality assurance, and ideally along with the consequences of not addressing it. It's such a clearer starting off point for discussions around if/when it should be addressed or not.

For changes that allow you to subsequently address a need, for example some types of refactorings, make sure to say that need when talking about it: "doing X will allow us to easily or more safely do Y" for example. Make sure it's clear that you're aware that refactoring is often necessary, but is never an end unto itself.

And finally, explain rather than apologise in almost all cases! Achieving requirements within constraints is something to be proud of, even if some decisions led to one of the many things that could be labelled as "technical debt". If you've not done X, Y, or Z because they weren't as high priority as other things, that is something to feel good about, not guilty (as long as you haven't made it meaningfully harder to do those things if/when they are needed). Apologise only if you've made a mistake and would not take the same steps next time.