I posted yesterday about the thrill of having to get something in a hurry and as a couple of commenters rightfully pointed out, there is a dark underside to that situation. Namely technical debt.

Technical debt takes a lot of forms, from “well, just install it locally” solutions when something goes wrong with deploy, to code that you know just isn’t what it should be, but it’s quick.

We almost never get to go back and clean up technical debt, instead it just keeps accumulating. Like real debt the longer it sits the more interest it builds up as other pieces of your application come to rely on that badly formed code.

There are a few ways to approach the technical debt scenario, but rest assured that if you don’t clean it up you will regret it eventually.

Make them understand

Whoever “they” are, make them understand that spending time now to pay down the technical debt you’ve accrued in hurriedly fulfilling their wishes will pay back dividends in the end. If “they” are business people, put a little effort into estimating the effort and cost. I know that can be hard to do, but suits love spreadsheets. The larger and more convoluted the better.

Pad your estimates

Don’t say “That code already exists, so this should be easy” if you even suspect that code reuse means propagating technical debt. It is not unethical to hold your tongue if the result will be the time you need to make cleaner, safer code that will help the company and your fellow developers in the long run.

This works best when your boss doesn’t know much about code, which is true all too often.

Use this one carefully.

Dont Repeat Yourself

This little catch phrase doubles as a way to pay down your technical debt. If you have code that does basically the same thing and it makes sense to modify it to handle both your new and legacy scenario (while getting read of that nested if statement that just drives you batty), do it. It will allow you to dispose of legacy code while preventing unnecessary growth in your code base.

As a bonus, if the code your replacing wasn’t under a proper test suite, like most serious technical debt, then you have a great chance to expand your test coverage at the same time.