This is easily acceptable as true but practically it seems so easy to abuse since there isn't any real data or standard underneath it in terms of when it starts to make sense to pay off.

No one really knows from the outset what level of techdebt is necessary to succeed, and if the techdebt appears costless (since, unlike the metaphor of paying off financial debt, the interest payments feel relatively invisible), you're always going to have people counseling risk and that it's better strategy to move forward as "fast as possible" right up until your younger faster competitors pass you by.

I don't have clear ideas either on when it's a good idea to pay off techdebt, to me it generally seems to be a good idea to aim on "as soon as humanly possible".

If people get too aggressive on solving tech debt then it turns into gold plating - creating tech that anticipates too much and then gets discarded when anticipations prove false. This is relatively easy to recognize when it happens and is a good indication that you're going too far. Up until that point, though...

I disagree that the interest costs of technical debt feel invisible. I personally feel a very heavy burden when cutting technical corners / coding to specifics rather than the elegant generic cases. Indeed I spend a large amount of time in meetings persuading non-tech people of the impact of their (often technical-debt unaware) instincts. If you are in an organisation which is unable to measure, even in broad terms, the impact of technical debt, then that organisation is probably not run by the kind of people who should be managing a tech business. It's why most successful startups in the past 10 years have been run by people who understand code.

Yeah, I totally agree with you when we're making the distinction between tech and nontech people judging the techdebt.

@tunesmith I should add to my comment that I agree with you that many non tech people often treat technical debt as free. It's a big problem and is a major source of failure.

This is really wishful thinking about the nature of technical debt. Most technical debt is completely unnecessary and is due, entirely, to lack of planning and organization (in other words, operations problems). In a nice tidy perfect startup world your comment might make sense but that's such a small fraction of software businesses that no meaningful conclusion should be drawn from them.

This is analogous to saying no business needs financial debt, and can bootstrap entirely out of cashflow. It's baloney. There are many situations where you can do quick-and-dirty versus (slow) elegant-and-enduring, and there exist business (note I said, business, not technical) situations where the former is better than the latter.

The problem with the analogy of technical debt vs. real debt is that technical debt is the actual product itself. You aren't building a house using mortgage, you're building a house with shoddy materials and hoping you can flip it before it falls down on you.

I don't completely disagree with you at all -- there is a lot to building marketshare and having the dominant position. But I think you are way overselling it as an advantage. Being out in front and having the whole thing collapse on you is way worse than a slow start.

But again I think this conscious idea of doing quick & dirty is less prevalent than the debt caused by lack of experience and poor operations.

> This is analogous to saying no business needs financial debt, and can bootstrap entirely out of cashflow.

Technical debt isn't a commodity. You can't generally can't infuse legacy technology with more technology and fix things. At best there's a lot of bespoke work to get the legacy system to work with the new technology.

I agree, Conway's law, for example, has as much of an impact here.