In case you are not familiar with the term “technical debt”, it mostly means “messy programming”. Unfortunately, it is more serious than just ordinary messiness. It usually happens because a programmer was in a hurry and couldn’t think of a better way to make the program at-that-moment. Later-on, other programmers will see the code and think “why was this written like that? It would be much better if…”
Like with financial debt, there is interest. The “interest payment” for technical debt is “paid” by all of the developers who come in contact with the debt-laden code. Everyone takes a little longer to comprehend the code, or apply a fix without breaking everything. It slows everyone down, and this is the “interest payment”. It may not seem like much, but it all adds up. If the debt is big enough or continues to accumulate, eventually you could spend more time paying interest on your debt than doing actual work.
Have you ever wondered “why does it take these developers so long to complete (seemingly) simple or ordinary tasks?” This is a pretty good indicator of the amount of technical debt in a program. Imagine something simple that you might do, like making a PB&J sandwich, except the bread isn’t sliced and you are out of PB and J, and those are sold at different stores. That is technical debt. The task would take seconds if everything was arranged for your convenience and speed.
It sounds logical that sending a hundred dollars every month to a creditor, should pay down your debt eventually. However, that is largely dependent on your amount of debt and interest rate. If 9/10 of your payment goes to interest, then your progress is going to be low. A double payment is going to have a much larger impact, but you might not be able to afford it.
With technical debt, once a developer has waded through a file and negotiated his way through it, he will have a better understanding of the debt itself, because he has paid the interest. Now he can do his work (the reason he was here in the first place). There is something more he could do right now. Since [knowing the problem] is half the battle, he sees the technical debt (paid the interest). He could take a few minutes, or even hours to resolve the tech debt. Once the debt is paid, the team can enjoy the lasting benefit.
Finding a balance
Of course there are two problems:
1) YMMV – If the developer suggests that you just rewrite the whole thing, then you are less likely to get a good ROI. You really need to have a team policy about “how good are we aiming towards”. Don’t say “perfection” because that means something different to everyone.
2) Knowing when is a good time to fix it – Of course, it seems like a good idea to fix it as-soon-as-you-see-it, but that is not compatible with most timelines.
I’ve had good success with granting developers a budget of 2 hours per week, of tech-debt resolution time. The time can be applied at the discretion of the developer, but still needs to be documented and tracked. We don’t want developers getting carried away, after all. Any tech debt that takes more than 2 hours, goes into TFS first (or other work-tracking / requirements pool) and then it gets more evaluation: consider approaches/alternatives. Management can evaluate it and prioritize it. Just be careful to not burn up 4 hours to evaluate an issue that can be fixed in 2 hours. Show some good judgment.
Paying down debt it achievable and the ROI can be substantial. If you want your developers to get more work done quicker, then plan on making a few “double payments” and get some of that technical debt out of their way.