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?

  • 9
    Calculate it in into every feature you have to implement and don't mention it to the stakeholders. You could make it so that to them, it just is an additional effort, without knowing that you do the refactoring. Worked for me in the past. – Waldfee Jun 13 '13 at 8:36
  • See the answers to this question: How to Justify Code Refactoring Time – Amadeus Hein Jun 13 '13 at 8:51
  • Hmmm... if that's your real name then, if I were one of the stakeholders of the project, I wouldn't want to see that last paraghraph... Think about it. – Radu Murzea Jun 13 '13 at 11:21

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.

  • 2
    I would agree with "refactoring is just part of the process" if developers followed this from the beginning of the project. However, this is sometimes not the case and you get put on projects that are in active development but are hampered by technical debt that need to be addressed not simply as an 'I fix it as I go along' but 'We need to take 2-3 weeks to work on this problem' and potentially not deliver other features. – c_maker Jun 13 '13 at 11:05

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.

  • +1. Thank you for the reference to the article. I have been a developer for 5 years now and called every single activity that did not have to do with 'delivering new features' a 'refactor'. This is clearly wrong but was never pointed out to me before. – c_maker Jun 13 '13 at 11:17
  • Well, I guess we still need a superset name for "everything small or large that doesn't touch the observable behavior of an application". Oddly enough, Martin Fowler refers to it as "refactoring (verb)" - as opposed to "a refactoring (noun)", but I think it's a bit misleading. martinfowler.com/bliki/DefinitionOfRefactoring.html – guillaume31 Jun 13 '13 at 12:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.