[justinsteele]

Yup, if we want to beat the analogy further, I would say the constant attention to code "smells" and such is like cleaning behind the refrigerator daily when you see dust has landed. I think there is a great middle ground, where you actually consider the possibility that the improvement to the code will be a net loss (time investment to improve code and time it saves in the future). Lots of books about this, many people don't get the full theories, and instead take the talking points (x lines of code per method, don't do Y, do Z, etc).

[humanrebar]

The analogy falls apart when you consider that:

1. Fridge dust compounds linearly with time. Technical debt compounds faster the more technical debt you have.

2. Most of us aren't in the fridge business. The downside of a burnt out fridge is probably a lot lower than the downside of a terrible code base.

[DougWebb]

Technical debt only compounds if you're building on top of it. A module that is written once and never needs to be modified doesn't get any worse over time. Therefore, once it is working correctly, there is no point in wasting effort to clean it up until it needs to be touched again.

Note that I assume basic documentation, proper naming conventions, and adequate testing are part of "working correctly". Those are the things you do as you write the code initially. It's the refactoring/rework/gold plating that you leave for later, only if you need it.