Making the business case for a large-scale refactoring - Part 1

With a bit of discipline, we can make a factual business case for a large-scale refactoring that business people won’t resist.

The 2 previous 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 anything

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 define exactly what refactoring we want to do before making a business case for it.

Refactoring Cost

We pay for a refactoring only once, when we do it. The cost of the refactoring is the time it takes 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
• Build 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.

Non-Refactoring Cost

Contrary to the previous cost, this one 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 wasted or unproductive 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!

Photo by Nancy Van Schooenderwoert. Read the full story here

Lower productivity

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 ‘tasks’ for next iteration.

Next time we go through this meeting, we’ll need to estimate these tasks twice.

1. Do a normal estimation
2. 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

Payback Period

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.

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!