Refinance Your Technical Debt Just Like Your Mortgage

Technical debt always has the same 3 questions:

1. How much is the technical debt really costing us?
2. How much will it cost to pay down this debt?
3. How will I know it is time to pay down this debt?

If developers can not provide the evidence of business value for paying off technical debt (by answering all of these questions), the majority of the time project stakeholders will defer paying off technical debt.

So how does one answer all of these questions in a way that can be understood by a project stakeholder?

1. Keep track of time spent working around the debt

First off, is it really debt? Sure it might suck working with it…sure it might not be the new cool thing…but is it really debt? Is it really causing you slow down and pain? It is not debt if the pain is not measurable, and you can’t insinuate potential improvement if you neglected to measure it.

Measuring can be as simple as keeping a log of time spent fixing bugs in a particular area, or logging perceived extra time spent working around a crappy 3rd party library. In short, find a way to measure your pain in a quantifiable manner that can be perceived by anyone as money and time wasted.

Answers the question: “How much is the technical debt really costing us?”

2. Estimate how much it will take to pay off the debt

Estimating how much time and effort it will take to pay off the debt is perhaps the easiest of the questions to answer. Simply put together your battle plan for the refactor and estimate it out. Feathers in Working Effectively with Legacy Code might even suggest actually doing the refactor 70% through and then throw it away just to truly understand the size and steps to support the change for real.

Answers the question: “How much will it cost to pay down this debt?”

3. Determine a tipping point of when it makes sense to refinance (pay it off)

Now that we have measured both the cost of the debt (debt interest) and the cost of the refactor (debt refinance costs), we can frame in the answer to if it makes sense to eliminate the debt by using a house mortgage analogy.

When refinancing your house mortgage there is only one question, “Am I going to stay in the house long enough to see a positive return on the reduction of my interest over the cost of refinancing?”.

Simply put, if it costs $3,000 to refinance and it saves you $500 a month, will you be staying in that house for at least another 6 months in order to see a return on investment?

The exact same goes for software: if the data access layer is causing us 60 hours a month in lost time, and it will cost 300 hours to refactor, does it make sense to pay this off right now knowing we will see a return in productivity in 5 months?

Answers the question: “How will I know it is time to pay down this debt?”

To summarize, presenting the short and long term project costs of technical debt is as easy as putting it in a simple house mortgage analogy. However, remember that ultimately it is the stakeholder’s decision of how they wish to carry their technical debt. Perhaps it makes more business sense to spend more money now than save money later or they emotionally are just not ready to refinance. Make your case, show the business value, and the majority of the time you will get that signature for the refactor.