This question already has an answer here:
- How to justify code refactoring time? 7 answers
How do I convince project managers, product owners, business analysts, clients and various other stakeholders that refactoring is a worthwhile and productive part of the development process?
As developers we all know that requirements change or are never fully explained from the start, and therefore how we wrote a piece of code in the past doesn't make sense now and needs to change. We know that if we redesign a some code now it will save us headaches in the long run. We know that if we keep our codebase clean and tidy, it will improve maintainability and ultimately lead to better code.
But however I put this to stakeholders, I just can't seem to get the value across. To them, refactoring is an unconstructive waste of time (by its very definition - the user should see no change in the application). To them it delivers no business value (or at least no immediate business value) because it delivers no new features, and they will strongly resist any refactoring.
I can't be involved in a codebase where refactoring doesn't happen because I've been there before and I've seen how it ends up. So instead i sneak it in when working on a feature. I would far rather be doing it openly so the stakeholders can get a clearer idea of the development process.
Any ideas on how to get this across?