I agree. Technical debt is a very useful concept and it's not helpful to dilute its meaning.
Only a couple days ago I decided to change some data structure. It was needlessly hard because I had neglected to create an accessor function and was instead accessing it directly everywhere. Had to change every bit of code that accessed the structure's fields.
That's technical debt: something the programmer should have done but for whatever reason didn't. I paid back the debt by doing it: I created the function. Now if I want to change the data structure I only have to update the function. If I hadn't paid it back, it would start accruing interest: it would be even harder in the future as more and more stuff accessed the fields.
No sorry that is just bad encapsulation and goes under poor programming.Technical debt occurs when you write a good program to your current understanding of the solution knowing that the full understanding of the solution will come later, and that you need to do something now to get to that learning point later, and so you have to repay your partial understanding at the beginning with refactoring later.
Here, heed Ward words directly, poor programming is not debt, and debt doesn't cover "whatever reason programmer may have" but has a specific well defined scope: https://m.youtube.com/watch?v=pqeJFYwnkjE&t=198
I definitely agree with him about code reflecting one's understanding of the problem and its solution. I don't agree with the poor programming thing though. No one writes bad code on purpose. Sometimes things like that just slip through while I'm focusing on other issues. I do make an effort to polish things up before committing but at some point I have to decide that the code is good enough to push otherwise I'll succumb to perfectionist tendencies. I'm also a solo developer so I don't have anyone to review my code either.
I mean that is the guy who invented it should we just go "ah well the uneducated masses really wish for a term that excuses bad programming so let's twist this nice metaphor into something we can sell to management to that effect", or instead just get the quote and correct people whenever we can until there's no more shadow under which to hide bad code.
Only a couple days ago I decided to change some data structure. It was needlessly hard because I had neglected to create an accessor function and was instead accessing it directly everywhere. Had to change every bit of code that accessed the structure's fields.
That's technical debt: something the programmer should have done but for whatever reason didn't. I paid back the debt by doing it: I created the function. Now if I want to change the data structure I only have to update the function. If I hadn't paid it back, it would start accruing interest: it would be even harder in the future as more and more stuff accessed the fields.