How do you estimate a ROI for clearing technical debt?

Question

I\'m currently working with a fairly old product that\'s been saddled with a lot of technical debt from poor programmers and poor development practices in the past. We are star

Answer 1

I think you're on the right track.

I've not had to calculate this but I've had a few discussions with a friend who manages a large software development organisation with a lot of legacy code.

One of the things we've discussed is generating some rough effort metrics from analysing VCS commits and using them to divide up a rough estimate of programmer hours. This was inspired by Joel Spolsky's Evidence-based Scheduling.

Doing such data mining would allow you to also identify clustering of when code is being maintained and compare that to bug completion in the tracking system (unless you are already blessed with a tight integration between the two and accurate records).

Proper ROI needs to calculate the full Return, so some things to consider are: - decreased cost of maintenance (obviously) - opportunity cost to the business of downtime or missed new features that couldn't be added in time for a release - ability to generate new product lines due to refactorings

Remember, once you have a rule for deriving data, you can have arguments about exactly how to calculate things, but at least you have some figures to seed discussion!