Tracking Your Technical Debt to Keep it From Coming Back to Bite You

We all take shortcuts when we’re trying to get a project out the door as quickly as possible. Sometimes we just want to see if an idea will actually work before investing too much time in coding it up properly. Sometimes it’s just a question of needing to take a few shortcuts to actually make a launch date. And there’s more to technical debt than just what we inflict on ourselves: as technology advances, we know we need to go back and update our own projects — whether or not we have the time.

But those shortcuts advancements can add up into a mountain of technical debt and if you want to make sure that your particular project will actually survive for the long-term, you’ve got to have a plan in place for actually going back in and doing the work.

All in One Place

I’ve worked on projects (including a few of my own) where there were plenty of notes on work that needed to be done at some nebulous point in the future. There were piles of documents, notes on the project management software and even in-line documentation — a lot of which didn’t make sense when we wanted to integrate all of these notes into a cohesive whole.

The only real option is to choose one place to keep all of your notes for a given project and stick with it. You need to be able to quickly glance over what you’ve thought of so far and make sure that you’re not contradicting yourself on how you want to handle a particular problem down the line. Even if you’re just making a checklist of issues that need to be addressed, you’re going to be better off than the scattershot approach to taking notes.

What You Need to Track

There are a lot of potential sources of technical debt. The actual specifications of the project as it stands is a crucial place to start. Being able to tell at a glance if you’re using a particular API will help you tell if you need to rewrite some code after stumbling across the news that some company completely changes that API.

But go a little deeper. Make notes on each of these issues if they come up:

• Hacks and shortcuts, like where you’ve hard-coded some variable that needs to be changed
• Parallel development where you expect you’ll need to merge changes back into your code base.
• Pivots that require you to rewrite existing code to reflect how your project has evolved
• Testing tools that can make it easier to patch bugs

Updating those notes will make it a lot easier to actually pay back that technical debt when you’ve got the time to spend on it.

Image by Flickr user Vancouver Film School