We’ve all done it more often then we care to admit: that quick and dirty coding that works perfectly well for what it’s meant to address but which sets up roadblocks for future progress. A hurriedly fudged fix, maybe, that solved a sticky problem but locks you into a configuration you might not want to stay in forever. Or a new feature added on without much attention to what went before and no attention to what will come after.
You’ve bought a little time, but it isn’t free. Just as the interest on financial debts needs to be paid off, month by month, you’ll be paying for your messy code ad infinitum. Until you go and fix it.
Does that mean you shouldn’t ever accrue technical debt? Yes and no. In an ideal world, you’d want your code to stay perfect always, and you’d want to take the time to write all your solutions with a mind for the future.
But look, our world isn’t ideal. Just as there are times it makes sense to go and take out a bank loan—to buy a house, maybe, or to tide yourself through a lean time— there are times that you may do well to take out technical debt. When you’ve got a looming release date, for instance, and some super quick coding is the only way you’re going to meet it. When something breaks, and you’ve got exactly three minutes to get it working before the world comes crashing down. Or when you need that new feature yesterday and every moment counts.
Short term, taking out that ‘extra cash’ makes you feel on top of the world; agile, ready to attack anything. In the long term, it’s likely to slow down maneuvering and provide a drag on future progress.
So here’s a quick checklist to go through before you decide to take the easy way out:
- Ask yourself: Do I have to? If time pressure means the non-ideal, expedient solution is your only way out, go on and do it! Tomorrow can always take care of itself. If you’ve got a little potential wiggle room, though, go on to consider….
- What is the interest rate? How much of a drag will this put on our future progress, and is the time I’m saving now really worth it when looking at the bigger picture?
If you allow yourself to take out technical debt even once, there’s something you’ve go to remember: every moment of down time should be pay back time. Keep yourself accountable. Make a habit of refactoring on the go; using your low pressure time blocks to go back through the code and tidy up areas which are less than ideal. For larger technical debts or debts which have added up, you’ll want to schedule time blocks to go in with a sledge hammer and break down the uglies.
It’s not fun. It can be scary sometimes, and it is always singularly unrewarding: at the end of the day, after all your sweat and hard work, you have nothing new to show anyone. But if you’ve got good, clean code, your future self will thank you—and your work tomorrow, the next day and the day after that will be that much easier.