Often fixing a problem requires understanding both the problem and the specific code area where one wants to fix it; it may be cheaper to figure out the problem again later when we’re already working on that code area than to figure out that code area right now while we understand the problem. Often code quality issues don’t need fixing because the code in question is unlikely to ever be worked on.
There is too much to fix in one go, and it’s more important not to lose sight of actual user-facing functionality - that’s what the code is ultimately all about, after all. Code quality is valuable, but not infinitely so; we need to keep a sense of proportion.
This is one of the crispest ways I’ve seen this problem described. Kudos for the insight.
Often fixing a problem requires understanding both the problem and the specific code area where one wants to fix it; it may be cheaper to figure out the problem again later when we’re already working on that code area than to figure out that code area right now while we understand the problem. Often code quality issues don’t need fixing because the code in question is unlikely to ever be worked on.
There is too much to fix in one go, and it’s more important not to lose sight of actual user-facing functionality - that’s what the code is ultimately all about, after all. Code quality is valuable, but not infinitely so; we need to keep a sense of proportion.