Not all tech debt is created equal

Just like financial debt, not all tech debt is created equal. There is some you want to pay back ASAP and some you can slowly pay back over time just like the low, fixed-rate mortgages one could get in the past decade.

Surely, you would not borrow from this guy

On the other hand, if you borrowed money from the thug down the corner you'll want to pay him back right away. Credit card debt: you can give yourself some time, until the next sprint.

The question is, how do you tell one tech debt from the other?

We could start off by checking the 20 most edited files in the past two years. These frequently edited files could be our likely suspects:

git log --since=2.year --name-only --format='' | sort | uniq -c | sort -nr | head -n 20

We could then leverage our intuition of each file complexity to figure out the files which make sense to prioritize in a refactor. An alternate approach, depending on the repo size, would be to look at paths to identify modules, as opposed to single files.

A bottleneck would be a file or group of files which have been changed significantly more (i.e.: 2x) than others. Attacking those first would likely yield higher returns than a file that's only only one or two times a year.

Another tool that can help with this kind of analysis, and others, is Codescene: https://codescene.com/blog/prevent-technical-debt-from-crippling-your-organization