Let's fix the negative framing of technical debt

Technical debt is usually compared to letting a kitchen become dirty or taking a risk, a pragmatic compromise to get stuff done, something that at least makes the situation dire enough to take immediate action.

Making better things with borrowed money that one has to pay back later - with interest - is yet the nicest analogy found for this phenomenon (even though it invokes the picture of a bailiff), which is quite more diverse and wondrous than it may seem, as there are now far more things that we call technical debt, for example:

underlying technology developed and the code base needs to catch up

the developers have improved their knowledge of the language, libraries, frameworks or APIs they are using

a better understanding of the problem domain allows better solutions that need to be implemented

the development of different features on the same code base at the same time leads to a degradation of code quality

a feature toggle is not removed after the feature became the default

a minimum viable product (MVP) is not refined or removed after its initial creation

Basically all of this is more or less simple work that can improve the life of developers, the life of users and the life of managers who want their features delivered fast. So let's have a look at how these are negatively presented as tech debt (and let's try to put them into two categories):

Level-up

Level-up describes the process in which a dependency of the whole process, be it the developer, the language, API, external packages etc. improved over time while the code remained the same; it is only worse in comparison to what is possible now.

Usually, a level-up leads to more maintainable, concise code with less bugs, allowing to integrate future features faster. This is not a debt, but instead a sound investment in the future of the product's development.

This is definitely something both developers and management should be proud of.

Unfinished task

Be it a feature toggle that is not removed, a feature that is not finalized or has a lingering edge case bug, all of us have unfinished tasks. This sounds worse as it is, because it means that you are pragmatic enough to get things done fast, which is still a good thing.

However, when unfinished tasks amass, they can obstruct the development of further features. In scrum, the retro meeting is supposed to fix this, but since nobody wants to be the bearer of bad news, it is often overlooked.

A solution could be to equip every MVP story with an expiration date, at which the feature is either removed or finished. It must be long enough in the future to allow the collection of enough data on the feature's benefits. This cleanup task should always be part of an MVP's story.

All in all, technical debt is not as bad as it sounds. We should distinguish it into level-ups and unfinished tasks to avoid confusion and negative framing.

Please share your opinions and technical debt stories!