A mess is debt, because you have to pay interest on it. If you don't pay your interest, it will compound and completely kill your velocity. Nothing in Ward's transcript disputes that, nor would it matter if he did (Death of the Author).

Ward seems to be clarifying the difference between useful technical debt, which gets your product out the door faster, and wasteful technical debt, which is writing your code poorly when you could have done better.

If it's slowing your velocity down, making things harder than they should be, it's technical debt. I suppose if you had a "mess" that was self-contained, bug-free, and not slowing you down at all, then that's not debt -- but is it even a mess?

I've hear this before and I found it nonsense. In short, I don't see any advantage to distinguish responsible) deliberate debt from irresponsible/involuntary debt. A debt is a debt.

You take a loan to buy a house, knowing your salary will allow for the extra expense and you have backups plan. That's a responsible debt. Like, hardcoding some variables in a prototype - eventually that needs fixing. Everyone agrees this is technical debt.

But you can also take an irresponsible loan, eg for some far away vacations you can't afford to. Is that debt? Sure it is, and you better figure a way to solve it once you realize your mistake!

The reason for the distinction is that you basically cannot do anything about what you do not currently understand about the product (besides ship and iterate).

But you can do a lot about learning how to write quality software. And the more you do it the faster you'll get at it. It's only rational if you believe you'll have a long career programming to train how to make quality software, because many quality implementations are equivalently difficult to implement than low quality ones. For the same resources you get greater returns, and those returns compound as you are able to out ship your competitors and get more and more product knowledge/feedback.

From the transcript:

> I'm never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.

Oh I see: the distinction is to stop people frome shipping lousy code and saying "it's technical debt, we'll handle it later".

Ive been at the other end, when we're looking back at code and talking about technical debt, and there's been some semantic arguing about whether it was technical debt or not - I thought giving everything the name of debt would make the mission clearer (improve the code and reduce debt, which is a nice metaphor to communicate with others).

I'm still not entirely convinced by the distinction (we can just say: avoid taking debt if you can avoid it!) , but it makes more sense now.