I think classifying certain types of programming as “paying down technical debt” via “rewrite” can be harmful. In my experience, when people say “pay down technical debt” they often mean stop moving forward on the product and spend some time “rewriting” or “investing in infrastructure”. They do the work in a vacuum, without the context of actually solving problems / adding features. They end up either a) achieving subjective code beautification (“making the code less hacky”), or b) adding premature optimizations (“We need to add support for ___ so that we can scale later”).
Rewriting is almost never a good idea, as Joel Spolsky explained in a memorable essay. And premature optimization is “the root of all evil” about 97% of the time, according to Donald Knuth. Bug fixes removed in the name of clarity will have to be re-discovered and re-added; wrong-headed optimizations will have to be removed.
And who decides which code issues should be classified as “technical debt”? It seems very subjective.
Programming isn’t a code-production activity, it’s a knowledge-acquisition activity. Good programmers don’t focus on cranking out code and then fixing it later. They continually rewrite code as necessary to solve problems / add features / improve performance as their understanding of the problem increases.
If you’re managing programmers and they say something about accumulating technical debt, ask them about it. Ask why they consider it technical debt. Have a discussion about what it really means and whether it’s a valid concept or an excuse.