Technical debt is an issue that all programmers have to deal with at some point in their careers, and more often than not, it’s an ongoing issue. What is technical debt, you ask? When you do something the quick & dirty way, such as patching up a bug without fixing the underlying issue, or prototyping a new feature and using that code in your live environment, you accrue technical/code debt.
Like most forms of debt, you have to pay interest on technical debt, in the form of extra time spent working with said code at a future point in time. That bug you patched up might cause other issues somewhere else in your code, but you want remember why in 6 months or if somebody else takes over your project. They’ll have to track down the cause of the unexpected behaviour and fix it again, which will take longer than fixing it the first time around, when the issue and cause was fresh in your mind.
It doesn’t matter how good of a programmer you are, you’re going to accrue technical debt in your codebase at some point. Most of the time, you patch up a bug or push prototype code live to meet some deadline, fully believing that you’ll fix it later. The problem is, new deadlines pop up, your boss wants new features added, and 6 months down the road, that bug still only has a bandaid on.
Getting the time to go through and pay off your technical debt isn’t easy, as management probably won’t understand why you need to fix something that isn’t broken. Your best bet is to explain to them how it’s going to cost you more and more time going forward if it’s not fixed now. It may take you 10 hours to fix immediately, but in a year, it’s going to take 10 hours extra for every change you need to make to the system. Another form of technical debt is messy & hard to read code. If you don’t refactor it, you’re gonna keep changing it, adding more features, and after 6 months you won’t know how it works, why you did something they way you did, and good luck explaining it to somebody else.
Paying Off Technical Debt
Paying off your technical debt isn’t hard if you learn to constantly refactor your code. There are many reasons you should be refactoring your code constantly, and many benefits. With every new commit or feature, you should be fixing something in your codebase. This is how you manage technical debt.
If you’re a good programmer, you are constantly improving, learning new techniques, new functions, and learning new information about old functions. If you are constantly refactoring your codebase, you may see something you did 6 months ago and realize “Hey, if a user passes this function a malformed string, it will delete my entire database! I’d better fix that”. You could see things you did inefficiently, or in a confusing, round-about way. You can refactor the code and commit it with your next update.
If you’re constantly doing this, you’ll find technical debt is easy to manage, and you’re codebase will constantly be improving! It’s benefits everybody, and doesn’t take that much extra time if you stick to refactoring small things most of the time. Sometimes you’ll have to refactor huge components as well, but the majority of commits can just contain small improvements.