The Three Types of Technical Debt
All software has some amount of technical debt. And if it doesn’t today, it will tomorrow.
Technical Debt We Explicitly Create
We are diligently working on a project. We’re adding unit tests. We’re following proper red-green-refactor methods. But we still need to worry about deadlines. We find code that needs rework, but we don’t have time. We go into our ticketing software and create a new technical debt user story. But time and money are constrained resources. The software ships without resolving that debt. Those stories stay in the backlog, waiting for developer availability.
Example: I am working on a code base that still accounts for the Indiana time zone, even though it (mostly) switched to Eastern Time in 2008. But I’m working on a different user story, and I don’t have time to fix the time zone-related code. Right now, we must recognize that we are consciously making the choice to let irrelevant and out-of-date code live in our software. It works, because our quick-fix was to make Indiana Time function identically to Eastern Time. However, it is plainly wrong. Indiana Time doesn’t even exist, so why is this a setting in the code?
Technical Debt We Implicitly Create
We get better at our jobs. We improve our skills. We learn more about languages and frameworks. In six months, twelve months, or two years we will be better developers than we are today. Sure, the code works, and yes, the tests pass. If you ever have developers that want to redo something they just wrote six months ago, you are looking at implicit technical debt.
In the first condition, we saw problems but lacked the time to fix them. In this situation, we are creating more debt simply because we don’t know that we’re creating more debt.
Example: Why are we even dealing with dates in the first place? Even though we get used to working in our current time zone, we should really work as much as we can in GMT. The current time is simply GMT plus an offset. Four years ago, I never did this. However, after running into so many time-based problems in my development career, I always think in GMT-plus-offset now, and I never store local times. Unfortunately, there is a lot of code that I wrote prior to this revelation that has not been updated to account for this new-found knowledge.
Technical Debt the World Creates For Us
The world moves on, these days faster than ever. Look at your smart phone. How many apps need to be updated right now? Between when I write this and when it is published, Google Chrome will update itself at least twice. Browsers change and web standards evolve. Operating systems change. Cloud-based vendors offer services that just a few year ago were not available or incredibly expensive. Old security algorithms become easily crackable, only to be replaced by new techniques.
We didn’t do this to ourselves, but we still must respond. If you have a web site, how does it look on an iPad? If you have desktop software, how is it going to work with touch response on Windows 8? Should I have a Metro version of my application?
Example: The day Indiana converted to Eastern Time is an example of technical debt the world created for us. We have dozens (hundreds?) of lines of code to work with various time zones relative to Indiana time. It all needs to go away; Indiana Time is obsolete. Any code relying on or accounting for Indiana Time needs to be refactored.
Keeping Tabs on Your Debt
Managing your technical debt is part of managing your product. It’s all about hedging your bets and understanding break-evens. Personally, pain is pain, and I will always be in favor of eliminating pain — for me or the next developer.
Keep on creating those technical debt stories, and make sure that you are keeping your debt in check.
