6 ms·

"Technical debt only hurts if you have to pay it back" To continue the "debt" metaphor, when your product dies, it debt dies with it (or if you switch technolo

"Technical debt only hurts if you have to pay it back" To continue the "debt" metaphor, when your product dies, it debt dies with it (or if you switch technologies, you might get a 'debt relief'). So for the thousands of startups and products that disappear or get pivoted before they can mature - it might be worth it to bet on not paying technical debt.

gwern 12y ago
Perhaps you could call that 'technical bankruptcy', as in, "we're declaring technical bankruptcy and writing an entirely new version".
- decwakeboarder 12y ago
  "technical write off" is probably a better term.
  - TheOtherHobbes 12y ago
    I don't think the debt metaphor works, because there's no real or implied creditor. (Except maybe time or entropy?) Technical mass might be better. The code keeps accreting, developer efforts orbit around it in ever-decreasing circles, and at some point it becomes impossible to escape from it. But is this really a technical problem, or a documentation and specification problem? If there's no separate formal model for the project, the code is the documentation, and that's never a good place to be.
- bcg1 12y ago
  Might be more like a "technical jubilee"
benjamincburns 12y ago
> 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.

gwern 12y ago

Perhaps you could call that 'technical bankruptcy', as in, "we're declaring technical bankruptcy and writing an entirely new version".

decwakeboarder 12y ago
"technical write off" is probably a better term.
- TheOtherHobbes 12y ago
  I don't think the debt metaphor works, because there's no real or implied creditor. (Except maybe time or entropy?) Technical mass might be better. The code keeps accreting, developer efforts orbit around it in ever-decreasing circles, and at some point it becomes impossible to escape from it. But is this really a technical problem, or a documentation and specification problem? If there's no separate formal model for the project, the code is the documentation, and that's never a good place to be.
bcg1 12y ago
Might be more like a "technical jubilee"

benjamincburns 12y ago

> 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.