Technical debt

Introduction

The term “technical debt” refers to messy source code, data, or architecture in a software system. It is commonly understood to represent a vague acknowledgement that the mess should probably be fixed by someone, somehow, sometime.

People hearing the term “technical debt” for the first time are likely to guess what it means, in broad terms, and to understand that it is undesirable; however, the real detriment lies in a concept which, although alluded to by the term, is not spelled out, and therefore hidden. As a result, people often fail to grasp the grave implications of technical debt.

This post sheds light at the hidden concept and shows the real problem with technical debt.

(Useful pre-reading: About these papers)

Definition

Technical debt is the entropy that keeps accumulating in a software system as more and more features keep being added without setting aside the time necessary to reorganize the system so as to properly accommodate the addition of those features. It happens to virtually every software project, virtually every time a new feature is added, and it is one of the biggest problems in software development.

Origin

The term was coined by Ward Cunningham in 1992, when he needed to explain the problem to an economist. He used financial debt as a metaphor, in order to speak in a language that the economist would understand.

Explanation

Adding a feature without first restructuring the system to properly accommodate the change saves time in the short term, so the feature can be rolled out faster; however, doing so introduces messiness, which makes it more difficult to add the next feature, and to do any kind of work on the system from that moment on.

This is like borrowing money to buy something right now instead of waiting until enough money has been set aside for the purchase: the problem is not only that the money will have to be paid back eventually; the problem is that interest now has to start getting paid on the borrowed money, and it has to keep getting paid every month, until the debt is paid back.

The real problem

So, the problem with technical debt in software is not only that the restructuring of the software system will eventually have to happen; if that was the only problem, the restructuring could keep being postponed indefinitely; the problem is that day-to-day work on the entire system becomes more difficult, and keeps becoming more and more difficult with every added feature.

Consequences

Allowing technical debt to continue compounding without curtailing it can result in the following:

It can cause software projects to suffer, because there comes a point where the amount of effort required just for coping with technical debt is equal to the total work effort available, at which point very little gets done anymore.
It can cause software projects to fail, because the work effort needed to reduce technical debt is also hampered by existing technical debt, so there comes a point where the project becomes unsalvageable and pretty much has to be thrown away and rewritten from scratch.
Even before things get to that point, programmers start feeling unmotivated and unenthusiastic about making any change to the system, and sometimes declare features as impossible to implement, not because they are in principle impossible, but because they are untenable propositions in the current state of their system.
Programmers start perceiving their job as a dreary chore, and may quit to find interesting and rewarding work elsewhere.

Conclusion

The real harm of technical debt lies in the extra effort needed to get any work done in a software system, like interest that has to be paid on financial debt. This interest is the concept which is alluded to but not spelled out in the term “technical debt”, and this is what needs to be understood for the realization to sink in that the debt must be paid off as often as possible, and as early as possible, instead of letting it linger on.