How to measure the potential value of refactoring

Question

On an old, large project with technical debt how can you reliably estimate or measure the benefit of refactoring code?

For example, say you have some components within a software stack solution written in an older language, and some later components written in a newer language. New features and bug fixes are constantly being added to this solution by a development team.

The developers suggest that replacing the existing old language components with the new version would be 'a good thing' However, no extra features would be added by this work and it will cost x dev-days.

A sales person suggests adding 'a great new feature'. the company measures the value of his suggestion by using a formula. ie. It will earn the company F million pounds, over t years at a cost of x dev-days work

How can the company cost up the refactoring proposal in a meaningful way? and under what circumstances is it likely to be the most profitable option for the company?

Answer 1

It will earn the company F million pounds, over t years at a cost of x dev-days work

Which is ignoring maintenance costs, support costs, the cost of sales/marketing, and makes a whole lot of assumptions about how the feature will be taken in the marketplace.

But whatever; your question is clear enough about what you're looking for:

How can I make a business case for refactoring?

The main thing to realize is that time equals money. You can go straight to "5 developers 2 weeks = 80 hours * 5 developers * $50/hr -> $20,000" and that makes sense to business people. Smart business people will note that those 5 developers are being paid either way, with which you counter that it's not spending/saving the $20,000 - it's using the $20,000 in the most profitable manner. Anyways, on with the list.

• Efficiency - Presumably, you can get more stuff done with C# than VB6. Better tooling, better libraries, whatever. Newer technologies tend to be better at things than older ones. If you can do stuff in less time, that means you're saving the company money.
• Overhead - Coding isn't the only cost of software. Consider what happens when Windows 2020 comes out. How much time and effort are you going to spend getting that VB6 app working on it? How much more time and effort is that than a C# app? That is saving your company money.
• Quality - Presumably, you can get stuff done with higher quality in C# than VB6 (or with a cleaner architecture, or whatever else your refactoring target is). Higher quality means less bugs. Less bugs means less cost to fix those bugs, less customer support costs to field those issues, less customer loss due to quality issues, increased sales due to a reputation for quality... all dollars for your company.
• HR Savings - Let's face facts: nobody wants to work with that shitty VB6 app. That means more people will leave the company leading to time and money spent to replace them. That means it takes more time and money to hire new employees. Worst of all, it means you'll have developers who are totally fine committing career suicide working with that VB6 app. Those developers in turn hasten the death spiral of quality issues. Cutting turnover and hiring times saves your company money. Keeping complacent, crappy developers away saves your company.
• Morale - Similarly, the programmers that are already there hate working in VB6. They'll do it, and they might even do it well. But it sucks. Maybe not for everyone, but certainly for some. That means more time spent browsing the web to recoup motivation. It means longer lunches. It means less getting stuff done while your programmers take longer to recover from the sucky work.
• Capability - This is less applicable with technology driven refactors, but applies to architecture sort of refactors. Certain code problems actively prevent you from providing cool feature X to make tons of money. Maybe you can't scale. Maybe you can't get at the data to do cool informatics. Maybe the code is such a rat's nest that it is prohibitively difficult to actually do the work. Whatever. Sometimes you're at that point, sometimes you're driving straight towards that point. It's hard to translate to business-speak, but if you can the "this problem is preventing us from taking advantage of opportunities X, Y and Z" can be powerful.

All in all, it comes down to "this stuff will help us do our jobs better; if we do our jobs better, we can make/save you more money".

Answer 2

The question you should ask yourself is how is the salesperson know that the feature will cost x developer-days of work. Given that even good project managers with years of professional experience cannot often tell that, such data coming from a salesperson seems extremely... speculative.

According to my experience, salespersons usually don't make estimates, but guesses about how much is too much for management or customer: if management is ready to pay 50 man-weeks of work, but will absolutely reject 75 man-weeks, let's tell that the feature will take 70 man-weeks while being ready to renegotiate (something which is out of question for a real estimate) down to 55 man-weeks.

• On one hand, you have estimates done by IT experts telling something like:

  According to this specific audit, we are wasting $8 000 per day using an outdated technology compared to similar projects of similar size which use newer technologies. It also appears that it will take from 50 to 80 man-weeks to migrate the whole code base; during this time, there would be no new features released. There is also a 10% risk that migrating a specific component may result in 20-30 additional man-weeks of work.

• On the other hand, you have guesses done by salesmen, based on their leverage when negotiating with the person they need to convince.

It's all about how influential you are in your company. Communication is key here, and this is where salesmen usually win over IT professionals when it comes to explaining the benefits of a feature to management (or a customer).

Note that if in the past, your estimates were quite precise, you gain reputation and influence. If your estimates were always wrong, management would probably ignore your proposals.

As for the estimates, it is extremely difficult to make a valuable one here, since there are a huge number of parameters to take in account. Among others:

• Do you actually know how skillful is your team in C# compared to VB6? Is it based on actual measurements or just guesses?

• Have this team developed large projects in C#? Do they know the tools they should use (IDE, debuggers, profilers, etc.)? Do you need additional licenses (which, in Microsoft's world, mean thousands of dollars per machine)?

• Is the current project totally clear and you can guarantee that there will be no surprises when migrating? Is it straightforward to rewrite everything, every feature, or would there be surprises?

• Do you have the infrastructure which supports C#? What about continuous integration? What about your build server? Style guides? Static checkers?

• In production, are servers (if this is a web app) or customer PCs (if this is a desktop app) able to run the version of the .NET Framework you are expecting to use?

But the most important thing is to know why do you want to rewrite everything. What is the problem you are trying to solve through a rewrite? A loss of productivity? How do you measure it? How do you show this loss of productivity to management?

Once you have shown that you are wasting, say, $8 000 per day because of VB6 (which means that you'll save $8 000 per day once you migrate to C#), how do you explain the benefit of holding every new features development and focusing on a complete rewrite? What's the benefit compared to progressive rewrite where you migrate your components in small chunks one by one, while shipping new features?

Answer 3

Firstly, you need to estimate the dev cost for the re-factoring as you would the sales driven feature request.

This may well be tricky to get accurate if it's a large job but, assuming you have sufficiently experienced people in the 2 technologies, it should be doable.

Secondly, you need an estimate of the cost of not re-factoring. If you were doing the estimates for me, I'd expect some level of metrics. For example, the difference between the average dev cost for VB code and for C# code over a quarter. Or some such. Will obviously depend on how accurately you track this.

With these 2 numbers, you can estimate the pay back period that the re-factoring will give you i.e. at what point will the re-factoring turn from a net cost to a net gain.

I can only guess as to how persuasive any given result would be. However, if it's less than a year it'll probably be quite strong, much more than 2 years then you may well struggle.

Additionally, it's probably worth adding other dimensions to help build your case. One that I've used in the past is seeing if any exit interviews cited the technology as a driver. If so, you can argue that the re-factoring will retain staff (hiring and training being v expensive).

Obviously, you can argue these things without supporting evidence but I find that it can make a huge difference to the impact of the case.

Answer 4

The value of refactoring comes up in multiple different ways.

It helps you make other changes later, so the X days the that feature would have taken would now take 2/3X days to complete. To use the agile terminology it increases velocity.

The explicit change listed would over time help since you would no longer need to maintain developers with VB6 experience, only those with C# experience.

It also helps in other less tangible ways like staff retention and recruiting. Would a job doing C# and VB6 be more or less attractive than a job doing just C#? Would you be more or less likely to take a job or stay at a job working on a nice code base or a lousy one?

Answer 5

I think the point the other answers miss is you need to measure the cost of refactoring against the lost revenue from not refactoring.

Refactoring for the sake of changing code is a waste of time. It needs to bring value to the table. In this context I do not mean spending an hour refactoring a problem class, but the major refactoring such as changing to a different CLR language as you used in your example.

• If we keep doing what we are doing, are we missing out on something? Is there a crufty old design in place that is holding us back from realizing value? For example, if we want to add a feature is it so difficult that it might take e.g. 100 hours to implement, vs. 50 hours to refactor and 25 hours to implement against the new design?

• Does the existing code carry technical debt that is costing us money? Is this crappy old code the source of bugs? Do we end up working for free to fix problems because of it? Nobody likes giving away lucrative billable hours for free.

• Is the cost of refactoring equal to or less than the cost of not refactoring?

• Is it possible to amortize the cost by having a small team of rockstars refactor the code causing the most problems? Can we spread the refactor out across releases? There are small inefficiencies everywhere: can we "fill in the gaps" so to speak with this extra work?

Answer 6

Benefits of having a refactored system

You make a business case for refactoring by comparing the business bottom-line benefits between doing and not doing it. It means either reduction of current real costs, or an increase in future real cash inflow.

The key budget items affected by refactoring are the follows:

• Maintenance costs - if the current system is a fragile pile of spaghetti, and it is observable in practice that fixing small bugs (both in development and operations) takes a large amount of man-hours, then it could be expected that the costs of such maintenance will be smaller for a "properly re-designed" system. Take a look at what your annual pure maintenance costs are, and how they could realistically change after the rewrite.

• Cost of adding new features - again, if the current system design and structure makes it unreasonably time-consuming to write new features, then a rewrite might provide savings. Take a look at your planned budget for new features, but be realistic - if you claim that you'll see a 50% improvement then expect to actually develop features in x man-months that earlier took 2*x man-months to realize; such promises may be hard to keep.

• Software quality impact on sales - if the current system is frequently causing customer-visible problems e.g. crashes or downtime despite adequate maintenance effort, then a rewrite can be a solution. IF this is a major issue, then the same sales people can quantify the value of a 'feature' called 'more stable product'.

If the three points above don't reach the expected cost of rewrite (and more; opportunity cost of spending x dev-days on not-features is equal to the value of those features, which is larger than the pure cost of the x dev-days) then I'm afraid that that's it - the expected savings don't justify the rewrite.

Also, if your roadmap doesn't show a need for 'as much as you can provide' new features, then the savings should be in a form 'it used to take 10 people to do all the required stuff, but after the rewrite we'll be able to do the same with only 6 people'. If you can "sell" more development projects than you have developers, then improving efficiency allows you to develop more things, but if the business with the current resources is already able to develop all the things that bring extra value, then the only financial benefit can come from paying less people or having cheaper people.

Answer 7

The value of refactoring can be measured like so: currently new feature x will cost 5 devs 2 weeks. If we refactor y old component, the cost of new features will be reduced by an estimated 20%. So new feature x will only cost 4 devs over 2 weeks.

Refactoring is an investment in reducing the cost of future developments. If you can't make that argument for your refactoring, there probably isn't a business case for it.