Technical debt refers to the work that you leave for your future self when you take a technical shortcut in order to finish a project or feature sooner. This might be deploying code before it's fully documented, tacking a one-off feature onto an existing system that it doesn't cleanly fit into, or simply throwing in a hack in order to fix a bug. Technical debt acts much like monetary debt and is a surprisingly good metaphor.
Technical Debt Isn't Always A Bad Thing
Imagine that you're working on building out the new version of your company's flagship application. It needs to go to market in a few weeks so you decide to skimp on technical documentation for it. After all, it's just your team maintaining it and they all understand how it's put together. You'll write the technical documentation for future developers at some point in the future when you get a chance.
This is a reasonable choice. Getting the app to market on-time will probably generate more value for your company than the extra time which might be lost due to not having good technical documentation. If you pay back the technical debt relatively quickly and catch-up on writing the documentation, then taking on the debt in this case was the right choice.
Technical Debt Accrues Interest
Let's say that once your app goes to market, your team gets bogged down with bug fixes and customer requests. Writing up the documentation takes time which you don't have. Your team hires a few new developers. As the new developers start, it takes them weeks to figure out how the app is put together and the senior developers have to spend hours training each one and explaining how the system works. This time cost will continue until the technical debt is paid off and the system is adequately documented.
Interest on Technical Debt Compounds
Much like how monetary debt charges interest on top of interest, technical debt leads to more technical debt. Continuing with the example of the skipped documentation, some understanding of the architecture will inevitably be missed as new developers begin working on the system without documentation. New features will be built that break the mold and even if they work, now every discussion of application architecture will begin with "so originally, it was supposed to work like…". Over time, you find it takes a full history lesson on the application before anyone can be productive with it. As the architecture frays at the ends, bugs become more common and each quick bug fix has the potential to further worsen the problem.
Not All Technical Debt Has The Same Interest Rate
Anything that's off the perfect happy path of software development best practices introduces some degree of technical debt. Not all technical debt collects "interest" at the same rate, though. Significant architectural shortcomings in an app that's maintained by a large team who interact with the code on a daily basis will cause far more pain than taking a shortcut in an application which you only touch a few times a year. Likewise, skipping some documentation on code which is relatively self-documenting won't cause as much pain as failing to document the underlying requirements and use cases for a system. Going back to the first point that technical debt isn't always bad, but consider the "interest rate" on that technical debt.
Use Technical Debt for Safe Investments
Maxing out your credit cards to buy lottery tickets is a pretty surefire way to find yourself in deep water. Taking out a mortgage to buy a house can be a step towards building a strong financial foundation. In our example of the missing documentation, it was originally a fairly safe investment in a new and improved version of a well established app with a solid user base. The rates on missed documentation were initially low because the team mostly could get by without documentation. It wasn't until the rates started to rise as new developers joined the team that they found themselves in trouble. As long as you can make regular "payments" in the form of refactors and code clean-ups, these technical debts will be paid off over time. Adding in unproven features and taking on technical debt to get them deployed is a much riskier prospect. Sometimes it pays off, but you can also find yourself with a worthless feature and technical debt left over from implementing it.
Paying Off High Interest Technical Debt is a Safe Investment
In general, paying off debt is a safe investment. If you have credit card debt at the US average 19% interest, paying it off effectively guarantees a 19% return on investment, far outpacing stock market returns without the risk of market fluctuations. Although it may not feel like you're making money by paying off debt, it's one of the most powerful investments you can make. The same is true of technical debt. Paying back technical debt on the worst legacy applications can seem insurmountable, but it will make the most difference. Even dedicating a few hours a week to cleanup can be one of the most effective uses of development resources over the long run.
Technical debt can be a useful tool, but when it gets ignored or out of control, trouble will follow. Consider decisions which will introduce technical debt and make them deliberately. Think about the rate at which your technical debt will build up. If you do take on technical debt, come up with a plan for "paying back" the debt, and make sure to make regular refactors and cleanups.
Cover Photo credit Colin Watts on Unsplash
Top comments (4)
I have never been interested in it because I always give money back in time. So, I have never had problems with collectors and I am happy about it. Perhaps I am too responsible and it takes away the excitement that I should feel.
you are right. It is always better to pay on time. But a debt recovery agency is not necessary a bad experience as a debt collection debt collection is about accomodating all parties and discuss best ways to repay a debt.
There are always measures like cyclomatic complexity, but I think those code-level metrics don't usually tell the whole story. Coming up with some kind of multi-category scoring model for technical debt would be a neat idea.
I think a sort of "rubric" model would be interesting where you could score from 1-5 in a number of categories like consistency, documentation, architecture, testing, and tooling, and then have a change frequency multiplier. So a perfect "zero debt" system would be one that had a well thought out architecture, applied that in a consistent way, had thorough unit and integration tests, and good quality automated build processes.
For a system which missed some points, the score would be multiplied by how often changes were made to a system, so that poor quality but infrequently modified part of the code might score similarly to an better quality part of the code which was in an editing hotpath.