What is Technical Debt?
First, what the heck is technical debt? Wikipedia says its a metaphor referring to the eventual consequences of poor or evolving software architecture in a codebase. Think of it like this. At the 11th hour when the head of marketing comes in and decrees, “This feature MUST be done by next week in time for the conference.” The dev lead says, “Ok, to do this RIGHT, we need at least 2 weeks” to which Mr Marketing says, “Just get it done!” No one wants to be the person who prevents the company from making a good showing at the conference, so the team does its best to shoehorn in a solution, cutting corners and optimizing for speed.
Let me say it again, “optimizing for speed”. This is important to mention because one of the most common causes of technical debt is optimizing for speed. You get it done, but at what eventual cost? The debt charges interest, and it costs you to carry that debt forward until you pay it down or pay it off. After a few months of “Just get it done”, you can no longer do it because the code base is in such bad shape. Features take longer and longer, and are more and more bug prone. Until the team is able to refactor code in order to pay down technical debt, its carried forward, drawing interest. Just like real debt.
How do you Measure Technical Debt?
This is a very good question. I don’t have a way to directly measure technical debt, but I usually say that for a stable system, if the team is spending more than 20% of their time on maintenance and bug fixes, that is a smell that means there are either code issues or architecture issues. Those kinds of issues usually point to short-term decisions being made in the name of speed (technical debt).
Aside from the issue of technical debt, there is also the notion of “technical credit” where teams proactively improve the system before there are problems. If there are no bugs or architecture issues, that 20% time should be used to create technical credit.