I agree with this history, but don't think the meaning was acquired independently so much as naturally grew. Ward presents it in a sort of "optimal development" context, where what we did last year was the right thing last year, but we know more now/things have changed and we know what the right thing would be today. This is definitely happens, but doesn't allow for a lot of other real-world reasons for this mismatch between the current and ideal state.
The effect is the roughly the same though, there is an impedance mismatch between what you want to do to/with the system today, and what the system actual is today, and that has a cost. The work of reducing this impedance is real work, and can be thought of as "paying off debt".
> Ward presents it in a sort of "optimal development" context, where what we did last year was the right thing last year, but we know more now/things have changed and we know what the right thing would be today [...]
Oh I suspect Ward's context was even more idealistic. That there was a problem to be solved, and there were few to no moving targets, the only differences over time were in the programmer's heads as they learned about the problem domain.
This is not the only factor in software development today, which is mostly a moving target (although I kinda wish it was, it's my favourite form of development, a clear goal and end state to achieve - aiming for maintenance mode on 1st release, or pretending you are getting a bunch of discs stamped - and I really like trying to break real world problems into these types of mini projects, but that's another story). Perhaps this is why it was inevitable for the phrase to take on a new meaning, and honestly maybe "debt" wasn't the best analogy anyway, your "impedance mismatch" is probably already a lot better as the sibling commenter points out.
> [...] but doesn't allow for a lot of other real-world reasons for this mismatch between the current and ideal state. The effect is the roughly the same though, there is an impedance mismatch between what you want to do to/with the system today, and what the system actual is today, and that has a cost. The work of reducing this impedance is real work, and can be thought of as "paying off debt".
The effect may be similar, but I think it's useful to distinguish the forces at play. In particular I believe conceptual mismatches as per the original definition of technical debt are catalysts of the "other" debts... The original form of technical debt is the most common attribute I notice in the vast majority of source: code is accreted, existing code, existing decisions are rarely questioned with intention beyond what is necessary to make the next requirement on the todo list function, and this tends to result in a lot of unnecessary artificial work and code to work around the exiting code base - which of course only makes it even harder to change.
> This is not the only factor in software development today,
I suspect it is a mistake to think that software development today is fundamentally different from how it was practised when he first wrote that. Possible application of recency bias..
I think this is right; the chaos of shifting or contradictory requirements can leave scars on the physical codebase reflecting this history, and so can attaining a better understanding of the problem from working on it, if one isn't careful to refactor (original sense) rather than adding new hacks on top. But the prescription for addressing each situation is pretty different.
> there is an impedance mismatch between what you want to do to/with the system today, and what the system actual is today
This is a better conceptualization compared to the idea that tech-debt is the result of shortcuts or rushed code. Tech debt arises for a lot of reasons, including shortcuts but not exclusively because of shortcuts. I've seen tech debt arise because well-meaning engineers were trying to do things "the right way".
I think it is just a kind of entropy thing that we have to fight against. A lot of confounding factors lead to code that is hard to maintain and extend. I think it is an unfair characterization to suggest it is solely because of laziness or negligence.
I've used the entropy analogy also. In particular, entropy always wins in the end. But I do think it weakens the "debt" analogy to consider it the same thing, because I like the idea that this is sometimes transactional - a choice you make for benefit now which has amortized cost. I think this is a valuable idea that is separable from the problems of complexity growth, entropy, etc.
I certainly don't agree with the idea that all technical debt is due to shoddy work, that's obviously silly. I suspect that people fall into it because it is easy to understand. The original framing is more nuanced and harder to think about but no less in effect.
To generalize that idea a little, I think about technical debt being the accumulation of less-than-perfect decisions, if you consider the decision you made against the best possible decision that could have been made in hindsight.
Sometimes that's not making things flexible enough, or too flexible, or not having all the requirements captured, or making technical bets that didn't pan out.
Indeed, there's a significant portion of technical debt that's created with the full knowledge that it isn't the optimal approach and will incur a cost of maintenance or use, but might still be the correct tradeoff at the time.
The effect is the roughly the same though, there is an impedance mismatch between what you want to do to/with the system today, and what the system actual is today, and that has a cost. The work of reducing this impedance is real work, and can be thought of as "paying off debt".