> 1. Most code will be rewritten every 2 to 3 years.
a.k.a. defaulting on the technical debt
a.k.a. defaulting on the technical debt
"The extra effort that it takes to add new features is the interest paid on the debt."
If adding a new feature starts with, "just throw out all the code and start from scratch", that's a much larger cost over the long term than building code that's easier to maintain and refresh.
(Mind you I'm not fully sold myself that 'technical debt' is a useful analogy at all)
Sometimes you can say "I know this will need to be rewritten later" and be pretty sure you're seeing technical debt be accrued.
But other times you have no idea. It might be a tool that was intended to be used for a few weeks, but turned out to be incredibly useful and lasted years. Had you known, you might have written it better if the first place.
Technical debt isn't like financial debt in that there's nobody with an accounts sheet telling you that you owe them anything from the start. You don't necessarily make a deal with anyone. So you can't judge its existence in the same way.
Research code is much the same. Your code doesn't have to be great (or even OK, to be honest) as long as it runs well enough to provide the results you need for your paper.
Likewise, rewriting a front-end in the framework of the week doesn't have to be because of technical debt; Angular 1.x was fine and it's still fine, however you'll see a lot of upgrade or rewrite projects happening right now not because of tech debt, but because people simply don't want to work in Angular 1.x anymore, or an employer can't find competent people that want to work with it anymore.
Likewise, COBOL applications aren't bad because of technical debt per sè, it's just become very hard to find people that can maintain it.