Compute costs of bad code

Question

I am looking for arguments to convince management to invest effort into refactoring.

We log work using Jira and relate every svn-commit to a jira call.

My idea is to do the following:

• manually spot an area of code which is extremely bad implemented, but often used: both from User-POV and of Developer-POV (bugfixes)
• get the svn-commits which contain the JIRA-Issues
• filter the issues according to some criteria (issue type, version, prio. etc...)
• compute the time/effort spent on these bugs
• estimate efforts and risks of refactoring
• present the numbers and ask for effort to fix it.

What do you think of this? Would such a measurement be useful and/or convincing? What are the Pros and Cons?

Answer 1

I've found that if you can provide valid numbers, managers are more likely to act. (If they can understand the logic and the cost/benefit.)

IMHO, to make a convincing case, you would need the following to show how bad it is:

• number of support incidents logged for the issues
• time spent in hours maintaining/band-aiding bad code/doing support fixes
• time cost based on hourly rate of people doing the maintenance/band aids/support
• some way to demonstrate how mission critical these items are to the business

And to make the case for refactoring, you'll need:

• time estimate to refactor and implement each of the top 3 of these bad things
• cost estimate for implementation (same hourly rates as used above)

With these, you can make the case for time savings if the refactoring takes a whole lot less than support time for 3 incidents for each of those top 3 items. You can argue that this shorter amount of time spent will

• be less than n more support incidents
• there won't be any more of these incidents for these things (EVEN BETTER!)

However, the hardest part of this sell will be answering the following question, since lots of people don't budget time in schedules for all the support you're doing:

How much longer will I have to wait for current project Y to get done while you're spending time working on these issues with X????? (despite the current support timesinks, which can't be predicted and scheduled in Gantt charts)

This depends a lot on how well you communicate with the decision makers, and how they understand the situation.

I DEFINITELY think this is worth doing, so you get the practice of building the case with the metrics, and to save yourselves time, even if they don't go for it. Unfortunately, not everyone is easy to convince, despite the data. GOOD LUCK!

Answer 2

Keep in mind that refactoring introduces bugs as well (which you will catch in your testing, but nonetheless are bugs and must be fixed). Don't pull a Netscape on accident. It depends on your personal definition of "refactoring." To some, this means "rewrite all the code" to others it means "change some internals." How do you tell what kind you are? Ask yourself the following question:

Am I changing the public interface at all?

If the answer is yes, you are doing redesign. If the answer is no, you are doing refactoring and can probably just do it along the course of your daily activities without special approval. This is relevant to your question because a redesign will generate many more bugs, while a refactoring is usually easier to perform (since your tests will already exercise the public interface and will not themselves need to be modified).

It is a difficult case to make, because no one ever knows how much X would have cost with or without the refactor that was done a year ago. In my experience the pragmatic managers always shoot this kind of thing down because:

1. No direct revenue stream comes from the effort (financial cost, not billable)
2. Ugly working code is still working code, you risk creating problems instead of fixing them (potential quality cost)
3. Other projects will be delayed while you refactor (time cost)

Answer 3

All such numbers are ultimately based on guesses, in your case comparing the amount you guess it would cost not to refactor vs. what you guess it would cost to refactor. The best you can do is show you have some kind of numeric, factual basis for the guesses, and you have a pretty good one.

The pros are that it will probably be effective in convincing them to let you refactor, and it might go well and reduce the number of bugs.

The cons are that if the amount of time spent fixing bugs doesn't drop by at least as much as the time spent refactoring, you probably won't be allowed to refactor anymore, and you will probably be blamed for the "wasted" time.

The savings in debugging time gained by reducing complexity of the overall project, or in making it easier to add features, may be too hard to measure to help you much, but you could mention that those exist.