> or if you switch technologies, you might get a 'debt relief' There's no free lunch here. When you do this you either pay off some of the debt by removing som

> or if you switch technologies, you might get a 'debt relief' There's no free lunch here. When you do this you either pay off some of the debt by removing some value from the product, or you spend ages just reaching "value pairity" at which point you've likely accrued a whole host of shiny new technical debt. Per the top commenter (jewel), I have to agree that this article misses the most important chunk of the metaphor - interest. Any time you have to work around limits imposed by architecture/technology/coding decisions, you're making an interest payment. Worse yet, side-stepping like the author describes is often like paying off one credit card with another - the premium compounds which dials up the interest payments. All of these sorts of things distract from delivering value and serve to further increase scheduling risk. Point being, the author is correct that the case of having to make a large pay-off in order to move forward is quite rare. However, that doesn't mean that you should disregard good project planning and discipline. As you point out, there are cases when you should take technical debt deliberately as part of some tactical decision such as when you are just getting an MVP together, or when you need to deliver immediately in order to make payroll. However every project accrues technical debt which was not deliberate as well. Regardless of the cause, you'll find that just like real loans, payments against the principle amortize best when they're made early. That said, it doesn't make sense to pay off a loan when doing so might cause you to miss out on some bigger opportunity, like a huge sale, or perhaps simply not starving.