With a bit of discipline, we can make a factual business case for a large scale refactoring that business people won’t resist.
The previous 2 articles were about how to present large scale refactorings to business people. This might already get us a lot closer to having our large scale refactoring prioritized. Unfortunately, many times this won’t be enough. Hopefully, we can add something to make the point to business people : numbers !
Business people love numbers. Presented well, they make decisions a lot easier to take. Making a business case is about estimating the costs of doing versus not doing a refactoring.
This is the twelfth 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.
Before we start any computation, we need to know what we are talking about. This means that as a team, we must agree and specify enough the refactoring we want to do. A small group design session might be useful at this point.
💡 We must detail precisely what refactoring we want before making a business case for it.
We pay for a refactoring only once, when we do it. The cost of the refactoring is the time it will take to do it. We can do a team estimate on the refactoring and see the numbers.
From my experience large scale refactoring estimates are pretty inaccurate. If the team is having a hard time agreeing on estimates, it’s a warning! Recipes against this are :
- Do a bit more design to better define the refactoring
- Take a safety margin for your estimation. Times 2 is not a bad ratio to start with (cf. the risk management section of The Art of Agile)
Eventually, be sure to convert your estimates in man.hours. If you don’t, it will be difficult to compare this with the non-refactoring cost.
Contrary to the previous one, this cost is recurring. We’ll only compute it for a single period of time, let’s say an iteration. It also works fine with a month, a week or whatever.
💡 The cost of not doing a refactoring is the sum of all the waste work generated by the current code.
The non-refactoring can be computed like:
non-refactoring cost = Bug fix time + Support time + Lower productivity
Bug fixes & Support time
Bad code generates bugs and support time. By doing the refactoring well, we’ll almost kill these wasteful activities.
We want to get the real amount of time the team is spending on bug fixes and support time related to our refactoring. Hopefully, our ticketing software might already contain enough time tracking data. That’s what I used when we did our improvement kata.
If not, we’ll unfortunately need to do a bit of manual time tracking for a while. It should be fine to cover a few days, and extrapolate for a longer period. Unbelievably, some people made time tracking fun by using Lego Blocks!
Bad code also makes us slow! By doing this large scale refactoring, we should get a productivity boost.
Here again, we are only going to measure for an iteration, and extrapolate for the future. If we are working with iterations, we should have an ‘estimation’ meeting of some sort. At the end of it, we should have selected a list of ‘task’ for next iteration.
Next time you go through this meeting, we’ll need to estimate these tasks twice.
- Do a normal estimation
- Now, imagine we did the refactoring. Re-estimate.
The difference between the estimates is the non-refactoring productivity loss.
productivity loss = normal estimation - estimation after refactoring
We need to convert everything in man.hours. We should now have figures for both total refactoring and recurring non-refactoring cost.
payback period = refactoring cost / non-refactoring cost
The payback period is the refactoring cost divided by the non-refactoring cost. It’s the time after which the refactoring will pay for itself.
To be continued
We’re done with computations. Next week, I’ll go over what to do with these numbers. We want to make business case for this large scale refactoring an unmissable offer!
This is the twelfth post in a series about how to get sponsorship for large scale refactorings.