3 ms·
I agree. However, "You know it's dirty back there, but it's not stopping the fridge from keeping your food cold." If you don't properly maintain your fridge a
by jrs235 13y ago
I agree.
However, "You know it's dirty back there, but it's not stopping the fridge from keeping your food cold."
If you don't properly maintain your fridge and allow too much dust to build up you could end up burning out the compressor.
Everything needs to be done thoughtfully, in moderation, and with purpose.
- justinsteele 13y agoYup, 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 13y agoThe 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 13y agoTechnical 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.