Technical debt is a term that denotes the additional cost of work (interest) in the future that results from choosing shortcuts or workarounds in the present instead of implementing a more robust design or solution. There are additional things that fall under technical debt, and we will get to these shortly, but this is what is usually meant by the term. It is a useful metaphor that allows us to assess the impact of our design choices, as well as to communicate the cost of these choices to non-technical stakeholders.
Much like financial debt, not all technical debt is bad. But, unlike financial debt, technical debt is inevitable. And much like financial debt, technical debt must be managed properly, lest you start drowning in it.
As stated earlier, when we choose a shortcut or a workaround instead of a more robust solution, we are creating a debt. Whenever we need to do additional work on related code, it will be costlier, and we will be tempted to accumulate even more debt. This is a form of intentional debt.
But it is important to note that technical debt is also self-generating and is thus inevitable. Technologies mature, change and eventually become obsolete. Unless you are working on a project that is in maintenance mode only and no new development is being done, the obsolescence of the project’s tech stack is also a form of technical debt. Sooner or later, you will have to replace the old with the new. This is a form of inadvertent debt.
The growth of a project over time also inevitably causes technical debt. No matter how much effort you put into future-proofing your design, it is impossible to foresee every possible direction the project might take. That is why, every now and then, a larger refactoring is in order. This is also another form of inadvertent debt.
As mentioned earlier, not all debt is bad. For example, debt created in order to not miss a critical deadline is a good debt. We frequently see this kind of debt in startups, where delivering quickly in the beginning is paramount.
On the other hand, debt created because a complex functionality needs to be extended and nobody wants to spend the time to truly understand it, thus using cult programming and copy/paste to hack the extension, is a bad form of debt.
A debt that is in a small, isolated piece of code that is rarely touched is a good debt, as the interest on that debt is low. A debt in a piece of code that is widely used and often changed is a bad debt, because the interest on that debt can become crippling.
The impact of technical debt is not just in the form of time/money. It can also severely impact developer morale, if enough of it is accumulated. Working on code that has been hacked and stitched together with paperclips over the years and that’s held in place by a coat-hanger and some duct-tape can be soul-draining.
In order to effectively manage our debt, we must be able to track it, because if we don’t track our debt, we will never pay it off. This is usually done by putting new items on to the backlog whenever we create intentional debt. Then, whenever we have spare time, we should pick up one of these backlog entries and pay off a piece of debt.
However, paying off debt only in spare time is usually not enough, as there is very little developer down-time between the sprints, if any. That is why debt backlog entries should be estimated just like any other backlog item, and some sprint time should be dedicated to debt payment. This is also sometimes not easy to achieve, as the project management, particularly if it is lacking in engineering background, does not easily see the benefits of doing that, and sees no immediate business value in it. That’s exactly where the debt metaphor comes in handy.
When managing technical debt, we should also consider the nature of the debt. For example, it might be worth it not to pay off good debt, as the payment might be much more expensive than the interest on that debt.
In conclusion, technical debt is an unavoidable part of software development with a big impact, and as such, it should not be neglected, but carefully planned and managed.