I'm on the fence with this. Yes, you can ignore ugly code but if the goal of refactoring is to improve the overall design of the codebase and not fix bugs or add features, I would say you can refactor anytime as long as it's not labour intensive and affects those bug fixes or new features.

While premature code cleanup might seem like a waste of time, I don't think you can live by a blanket rule to never do it in case the requirements change a few weeks down the road. They will. And so will your code.

I think a clean codebase that's easy to navigate, manage, etc. without smells that will put off touching it is more adaptive to change. So when that new feature does come along you're not pulling your hair out because the design is ugly.

Of course if all you worry about is "does it work" then we could leave mainframe systems and aging client/server apps that have worked for years alone and never touch them. I don't feel that's a maintainable state to be in.

I'm experiencing this right now on my project. But I wasn't the one who created the code originally. So now I'm having to clean up someone else's mess, and I'm not always sure I'm comprehending what was intended. I vote for cleaning up as you cause a mess, which is the intent of refactoring.

Maybe if refactoring with a tool was more intuitive (and we had confidence that it would work!), ugly code wouldn't stay in a system so long? Dynamic Aspects has some demonstrations of a new kinda refactoring tool.