[mullr]

"Code boyscouting" is an excellent way to put it.

@yzhengyu's experience is representative of my own, though without the same degree of politics. Even in conversations with those who should know better, it's nearly impossible to put technical debt payback ahead of new business requirements. Attempts to quantify it (additional time to deliver = lost opportunity = money) are fuzzy at best.

I really think the only practical way to combat code rot is at the leaf nodes, without telling anybody. Perhaps we ought to have a secret oath that all developers take. "On my honor, I will do my best, to do my duty to Knuth and my Profession and to obey Postel's Law..."

[hammerdr]

We can all certainly try :) And, fighting in the trenches every day (taking some time to do some refactoring instead of calling a feature done) is a great place to start.

However, the code rot really needs to be understood by the upper management of IT. Having a solid grasp of technical debt, how much it hurts, how much debt you can take on and how long it takes to pay that down is the responsibility of any manager of IT departments. If management doesn't understand this, they are setting the products up to fail every 3-5 years no matter how hard the developers work at the leaf nodes.