[ahdh8f4hf4h8]

I have always done "just in time" refactoring - when a big change comes to a module and you're going to have to re-test most of it anyways, then perform the refactor, test the code/module, and then implement the actual change. It helps if you have some long term vision for the product, so you have some idea of future changes as well.

You want to avoid refactoring if no one else is going to test the change, or if your automated test coverage on the module isn't too good. It's too easy to introduce changes that won't be noticed before deployment.

Chances are most code already works well enough even if the design or code is suboptimal - often the system only changes in certain parts and changes there often. If you can identify the parts of your system that are likely to change due to changes in scale or business requirement, than that is a natural area to focus on in future redesigns or refactoring.

[convolvatron]

this is right. in particular its timely and easy to justify if you can reasonably argue that new priority work would benefit from the refactoring of adjacent components.