Mar 1, 2025, 3:23 PM@marick I suspect it's devolved into a synonym for "crappy code" that ought to be fixed but never is.
My understanding of the concept is that you deliberately don't care too much about doing maintainable or thorough because the benefits of it asap are a priority. And then you're supposed to pay it off.
What I like: code is never perfect, and if it's particularly imperfect and you need to be there again, you fix it first, without talking about debt.
Mar 1, 2025, 3:27 PM@marick Talking about technical debt, creating issues for it, letting stakeholders prioritize it, has its place but I think has a risk. Those tend to be always at the bottom of the priority pile.
I'd rather communicate to stakeholders that a priority that touches on messy code will take longer, and then fix any mess as part of the normal work.
@faassen My speculation – not yet confirmed with Ward – is that the metaphor was used to *not have to* explain programming to the stakeholders. To these stakeholders (I'm guessing), (1) debt is taken on to enable you to do something *now* that you'd otherwise have to do later or never, and (2) of course you pay it back.
It makes "as we learn more, we have to revamp old code" into a "sure, that's the way my world works" rather than a "justify yourself."
https://metaphor.wiki.oddly-influenced.dev/view/technical-debt
Mar 2, 2025, 12:18 AM@marick
My understanding is that it isn't about
code that's difficult as not enough has been learned yet, but code that deliberately takes shortcuts to accomplish its goals faster as a sounder (more accurate, featureful or maintainable) solution would take longer. Perhaps you argue that coming up with a sound solution that takes longer is always a learning process?
Mar 2, 2025, 12:26 AM@marick
Does the concept of technical debt only exist in the context of equally functional solutions to the problem, and the only difference is whether the history of the solution remains in the code or not, i.e it's only about refactoring?
Or is it broader than that and there can be externally observable differences beyond maintainability - performance, usability, missing features and the like? So the technical debt leaks to the outside, but may still be worthwhile to stakeholders.
@faassen Talked with Ward Cunningham today. Although he coined the phrase, it was not that important to the actual company where he coined it. (My belief that he used it to "sell" refactoring to the "suits" was wrong.)
So I'm now in the camp that we should just do away with it. It obscures more than it reveals.
Mar 3, 2025, 2:07 AM@marick Interesting! I think there are different points when one might use it to explain
* the cost of taking shortcuts explicitly for speed of development
* that it's unavoidable because we're always learning that debt accumulates
* why we should "fix" the shortcuts as a separate task, because they hinder development
* why a task will take longer as we first need to tackle the cost we incurred earlier
That's rather muddled. We could just use the words I just wrote too.
@faassen Yes. I think metaphors have a role. But I'm no longer sure the technical debt metaphor can be used to say anything much about the role of metaphor in organizing/aligning people.
@faassen The original metaphor is specific to an assumption that understanding of the problem ought to be embedded in the code, and that the history of design changes that led to today's code should not – it just makes things harder to understand.
But the point I'll try to make in the upcoming episode is that the metaphor lands differently for people who think debt is something to be paid back vs. something to be rolled over into more debt.