The term "technical debt" refers to messy source code, data, or architecture in a software system. It represents a vague acknowledgement of the fact that the messiness needs to 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 hidden concept which, although alluded to by the term, is not spelled out. As a result, people using the term often fail to grasp its grave implications.
In this post I shed light at the hidden concept and show the real problem with technical debt.
(Useful pre-reading: About these papers)
Technical debt is the entropy that keeps piling up 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, across space and time.
The term technical debt 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.
Adding a feature without first restructuring the system to properly accommodate the change saves time in the short term; 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 with borrowing money is not only that it will have to be paid back eventually; the problem is that interest now has to start being paid on the borrowed money, and it has to keep being paid every month, until the debt is paid back.
Similarly, in software, the problem is not only that the restructuring 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.
Allowing technical debt to continue compounding without curtailing it can have the following consequences:
- 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 unenthusiastic about making any change to their 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. In general, programmers become unmotivated to keep doing their work, and may even quit their job to find interesting and rewarding work elsewhere.
So, the real harm of technical debt lies in the accrued interest that has to be paid, in the form of extra work needed to get anything done. This interest is the concept which is alluded to but not spelled out, and this is what needs to be understood for the realization to sink in that technical debt must be paid off as early as possible, and as often as possible, instead of letting it linger on.
See also Technical debt in Wikipedia.
Cover image: created by ChatGPT with the prompt "Please give me an image of Sisyphus pushing the rock up the hill." and "Please give me the exact same image, but with the rock looking a bit more irregular, more like a rock than like a ball." (Note: it did not give me the exact same image; but it was very, very similar.)
No comments:
Post a Comment