Buy now, pay later – this slogan is used by furniture stores, fashion outlets and travel agencies. The offer is tempting, but one shouldn’t forget that in the end debt remains which has to be repaid. What does that have to do with software development? We are also sometimes indebted – we have technical debt. This blog entry shows how to identify it and where to start repaying in the most effective way.
What is Technical Debt?
The trouble with quick and dirty is that dirty remains long after quick has been forgotten.
Steve McConnell
This quote shows where we collect debts in software development – namely whenever we want to do something “the right way later“.
Documentation? Refactoring? Moving to another database? All things we do when there is time, it’s just that daily operations keeps on interfering and distracting.
The term I am describing here is technical debt. Just like their role model from banking and financing, we have to repay them at some point and they even accrue interest. In the case of technical debt, the interest consists of less and less output over time. Search more, swear more, we are becoming slower and inflexible.
Making Technical Debt Visible
Recognizing the problem and making it visible is the first and most difficult step. I often hear from discussions in client projects that technical debt is something esoteric and teams should rather continue to work on new features.
To prevent this perception, maximum transparency is necessary. For example: Whenever you find yourself saying “I’ll do it again later, but then I’ll do it right!“, raise a ticket. Collect all tickets exemplifying technical debt on a separate swim lane on your team’s Kanban board – this will serve as a gauge for the current “debt level”.
It is more elegant to use tools that actually calculate the technical debts of your own code base for you – an example being CQSE’s teamscale.
At this point, a word of caution: In the first couple of runs, such an analysis will report several person-years of technical debt!
How to Prioritize the Repaying of Debts?
Now that we’ve seen what technical debt is and how it can be surfaced, it remains to be clarified where it is most sensible to start reducing the debt.
Investing several person months or person years would mean that de facto work on the product would have to be stopped completely.
Here it helps to first consider the complexity. For example, a function in your code that is absolutely self-explanatory works well without any documentation, while a highly complex algorithm with recursion and jumps requires perfect documentation. Remember that you don’t document for others, but always for “future you”. A measure for complexity would be (among others) McCabe’s “cyclomatic complexity.”
In other words, technical debt reduction should start where the code is most complex.
In most code bases, however, there are a lot of such areas with high complexity – so we are back to the question: where to start?
My recommendation here is to put the code complexity in relation to the commit history of your repository – this shows you the heavily used files.
TL;DR
Just like in real life, it is a false economy when we try to save time during coding.
The longer you leave your debt unpaid, the harder it will be to get rid of it.
A common means for identification and prioritization of the debts as well as a realistic repayment plan are the result of a “debt counseling”, also for technical debts.
