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!

Comments

[Ingo Steinke]

Sandy Metz said to "go ahead, make a mess", but to contain that mess, which matches your kitchen analogy @lexlohr. Sometimes, its right to close the kitchen door (unless you live open plan, that is) and leave the dishes, because there are more important things to do right now.

Contain the "mess" (technical debt), concentrate on stability and maintainability of the important code that you depend on, an don't forget you might not gonna need to refactor some of the messy leftover anyway.

[Alex Lohr]

Make a mess that's easy to throw away. If it works out, improve until maintainable, if not, 🗑️.

[JoelBonetR 🥇]

According to my experience it's something like:

*project starts

- I need this features yesterday.
+ But ... you're even defining the requirements
- yup but start coding, I need it fast
+ ok but it would last a week at least, we need to do tests, documentation, the feature itself...
- Does the tests make me earn money? Does it the documentation?
+ no but...
- Ok so no tests and no documentation, do you think you'll be available to ship it to production tomorrow morning?

* some time after

- I don't know why the things are not working well, some clients are complaining about some bugs bla bla bla
+ It's not the best situation to add tests after coding the entire app but we can add tests to ensure that th....
- But I need this new features! We need to make money !

* developer1 goes to another company
* developer2 goes to another company
* developerN goes to another company

-F*ck now i've to pay more to new devs that know nothing about the current software and instead analysing the issue and hearing the IT professionals I'm gonna do exactly the same, what can go wrong?

This silly guy added tech debt on a software he's paying for being an ass instead fitting to the project development needs and adapt the rest to it. It's called business culture and it's something sad that happen on many places, specially on those where the boss is someone without IT knowledge that simply "want things"

[Alex Lohr]

That's not tech debt, but bad management and/or "missing/incomplete feature". Calling this "tech debt" is shifting the blame to the developers. This is part of why tech debt has such a negative connotation.