How to improve a factual business case for a refactoring to make it even more compelling to business people.
In last post, I explained how to make a business case for a large scale refactoring using real numbers. Numbers are great, but they won’t get us sponsorship by themselves. We need to understand them. We need to make sure they make sense. We need to make sure they are backing our refactoring up. In the end, we might need to improve them.
This is the thirteenth post in a series about how to get sponsorship for large scale refactorings. If you haven’t, I encourage you to start from the beginning.
What If Payback Period is too long?
If payback period is close enough, then great, we can go out and pitch the refactoring. Most of the time though, large scale refactorings take quite some time to payback.
Product Life Expectancy
The first thing to do is to put this in the perspective of the company’s or product’s life expectancy. Imagine a product which is 10 years old and expected to cash-in for another 10 years. In this context, a refactoring that pays for itself in 1 year is a great opportunity!
💡 The longer the life expectancy of your product, the more refactoring you should invest in!
Picking the age of the product as its life expectancy is realistic most of the time. New products have low life expectancy, but legacy systems seem to last forever!
Split the refactoring!
A strategy to reduce the payback period is to split this large scale refactoring. Can we make it smaller, more focused, or find sub steps that pay for themselves faster? Here again, incremental refactoring techniques will be critical.
Did we do an error?
It’s also possible that we did an error in the business case computation. Sampling and logging are error-prone techniques.
Is the iteration we took for sample is representative enough of the future work ? In doubt, we can re-do the sampling or the computation. Using better data leads to a better conclusion.
There are also other costs we did not take into account to be able to stick to man.hours. Let’s have a look at these.
Ideas for Improvements
Convert to Money
If we have access to money numbers, we should be able to improve the figures with new costs.
First, we’ll need the average wage of team members to convert our figures in real money.
If we have the figure, we can add the image cost of a bug to the non-refactoring cost.
Finally, if we have the revenue per feature, we can add the opportunity cost to the refactoring cost. Opportunity cost is the cost of not working on features !
Use a similar refactoring
Did someone do a similar refactoring in the past? If so, we can use it to improve your estimates about:
- Refactoring time
- Productivity improvement
- Time saved on bugs and support.
Is it a good idea in the end?
Are the numbers still arguing against the refactoring? Maybe it’s not such a great idea afterwards … We ought not to argue for something of dubious value, our credibility is at stake.
At this point, it might be a good idea to look for another improvement to do. Maybe there is other code to refactor or a new productivity tool to build.
💡 Avoiding bad moves is a key benefit of making a business case for large scale refactoring!
I’m fond of this way of prioritizing software. It’s the way out of bickering about best practices, and towards sustainable pace. If you want to learn more about this, here are 2 helpful references :
- A blog post Making Technical Debt Visible . It explains how to use the scrum sprint backlog to display the cost of technical debt.
- A PluralSight course Making the Business Case for Best Practices. It’s just great. It contains a ton of practices to help us to get realistic numbers and estimates.
This is the thirteenth post in a series about how to get sponsorship for large scale refactorings. We’re reaching the end ! In next week’s post, I’ll go over Business Partnership. There are some practices we can put in place once we have earned the trust from business people. Stay tuned !