How do I explain the value of refactoring to stakeholders? [duplicate]

Question

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?

Answer 1

I much prefer not to bother non-technical people with such technical details. To me, refactoring is just part of the process of delivering a feature (and thus is part of the estimation for the features).

If you really have to sell refactoring to non-technical people, I would sell it as a bug-prevention measure (by reducing complexity and duplication, you reduce the risk of introducing bugs) and a X-fold time-saver for the next feature (it is far easier to add new features to well-structured maintainable code). That way, the value is not so much in the business value it adds now, but in the increased productivity next week/month/year.

Answer 2

I think we need to distinguish between refactoring and redesign here.

• Refactoring is embedded deep into small development loops, it shouldn't span more than a TDD cycle or a task and should certainly not be a separate Story. It's one of those micro practices that make your code quality code. Since in Agile quality is not negotiable, and since refactoring is basically invisible at the stakeholder level, you shouldn't even have to tell your stakeholders you're doing it, much like you don't tell them you're using this design pattern or that programming style.

• Redesign on the other hand can last much longer. It's changing whole parts of your code base to reduce technical debt. It may be replacing tight coupling with dependency injection on a whole module, it may be introducing AOP to get rid of duplicate logging code, it may be revising the way your data access objects work to allow for more efficient database queries. Sure, you aren't changing any functionality, but the impact such large reworks can have on the project is worth mentioning to decision makers. This is where you typically create a technical story or a spike in your backlog after the stakeholder has approved the idea. Even if they're not that easy to find, there are generally more arguments you can use than with simple refactoring - performance, bug fixing, maintenance cost, deployment cost, codebase learning curve cost, etc. And if they don't deem the effort worthy - well, it's their product and you've made sure to warn them about what might happen.

So my advice would be : don't try to convince stakeholders about how you're working every minute as a professional - this is not negotiable. Try to do more refactoring so as to minimize the amount of redesign you'll have to justify afterwards.