4 ms·

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 de

by pnt12 4y ago

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!

maerF0x0 4y ago
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.
- pnt12 4y ago
  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.

by pnt12 4y ago

maerF0x0 4y ago

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.

pnt12 4y ago
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.