I have quite often meet with opinions that claims that business (by business I mean company) doesn’t allow the programming team to refactor or just put some time to polish code.
As definition stand for, refactoring is changing existing code without changing observable behavior. Think about it, and put yourself in business shoes, they usually don’t think in same way as programmers do, they may think.
Why should we pay for something that we don’t see result of. They did something wrong before and have to repair it now? Is it any new feature? What is the benefit of it? And answer to that is the key to success.
Most programmers are not the best in soft skills, but you must present refactoring as something from which business would take benefits from. Because that’s true.
Keep in mind what do you want to optimise. Take some indicators that measure it and predict how it will change after refactoring.
It may be time needed to deployment, to provide new feature or much faster software and much more work that employees may perform in same time.
Those scenarios are just example, but I hope that you catch the point, for all above, business would be happy for.
So to summarize, you must to ‘map’ programming language to business language and present benefits that will be results of refactoring. You don’t even need to use ‘refactoring’ word.