The term "technical debt" is poorly used. I hear folks of all stripes and roles proudly proclaim that they've "reduced technical debt" in some way. It's used as a catch all to describe some kind of supposedly beneficial change. I think it's just more software process word salad. Mostly because there seems to be some assumption that "Yay, that stuff that was changed is no longer a problem" when odds are that it will be changed again before too long for more "technical debt reduction". Software changes over time because the requirements change over time. I don't see the need for the phrase at all, and I think using it gives some false sense of accomplishment when really the constant change of code is the normal state.

I definitely agree that the "constant change of code is the normal state."

However, I think of technical debt as something that was taken from a spaghetti-like form of code to something actually utilizing a proven design pattern(s). As you say, change is definitely the norm, but change is so much easier to do when working with code that is written properly.

Another way to say it is that spaghetti code is very resistant to change, while code with design patterns is welcoming to it. Code that is change-resistant is technical debt.

Edit: Any kind of a shortcut taken to implement something is usually spaghetti code (because if it was written properly it wouldn't require a shortcut), and thus imo it is also included in technical debt.

Technical debt does not mean changes.
It means important things that have not been done to speed up something else. Short cuts, workarounds or similar things not done completely, that should have been done and will likely cause issues and more effort in the future.

Most of the time technical debt is just kept and everyone lives with the drawbacks. The usual 'temporary workarounds' you'll find everywhere. The things on the TODO-list which should actually be moved to a WE-DON'T-CARE-list

Ah, now both of you are quite specific about the term and use it in a way to describe something that is "deficient". My rant is more about the hijacking of the term to represent so much more that its become meaningless. Code that is obsolete, for instance. Is that technical debt along the same lines of a workaround that was never revisited? It's a gray area, but in the end, who cares? The phrase, used over broadly, gives a negative connotation to work done in the past, and is used far too often in a self congratulatory fashion when all that's really going on is "changes to make things work with the other new stuff"

@monkeyboy I see your point, and perhaps it has grown to be used for everyone and everything where its meaning is confused.

My initial reply was in response to: "I don't see the need for the phrase at all, and I think using it gives some false sense of accomplishment when really the constant change of code is the normal state."

Taking code from spaghetti to something incorporating SOLID principles for example that is also testable is by no means a false sense of accomplishment. It's literally taking technical debt and eradicating it, making it so you can now change the code with ease as requirements change over time (as you say).

I sometimes do reduce tech debt in my company. Usually, this means that the software does exactly what it had been doing before, but with a cleaner implementation. So, yes, it changes, but not requirement driven.

Another way is that I improve the documentation.

I just deleted 2000 lines of code, that’s a little less tech debt I have to wrestle with.