The amount of time, money, or effort it takes to work around, manage, and fix bad decision/implementation decisions. (CaseySoftware)
Put another way, technical debt is the sum total of all the hours you’ll have to work to make up for the design shortcuts and shortcomings you put into something.
Technical debt accrues in various ways – features are forgotten at design time and left out; mistakes are made in architecture; customers demand new features that will break other features. But I’ve found that every project accrues technical debt, and paying it down is critical to keeping the project on track.
I’ve got five techniques I use to help pay down my technical debt that I will share. Hopefully they’ll help you to pay down yours.
- Keep track of your technical debts. Keeping track of the debt through a bug tracker or list is the most important thing you can do. Try and keep the entries short (e.g. build new button for feature X). This will help keep the list a list of things you can actually accomplish.
- Aggressively pay down any debt you do take out. Sometimes this is hard, especially when your project managers are always pushing for new things and rarely give time to pay down technical debt. If you do step 1 well enough, however, many technical debt items can be paid off in 15 to 30 minutes, meaning you can pad estimates to allow for technical debt fixes.
- Borrow as little as possible. Insist on time to properly plan and architect any system. Joel on Software is big on the “No Code Without Spec” rule, and this makes a lot of sense. If you have a spec you have a blueprint for how an application will work at the end. The design process gives you an opportunity to go “well what if the client wants X?” And this creates a better product, that has less technical debt.
- Do not “balance transfer” your technical debt. It’s common in this day and age to balance transfer from a higher interest loan to a lower interest loan. Certainly there is a lot to be said for taking actions to reduce the accrued interest on your financial debt but I think this is a bit silly for technical debt. When faced with a situation where technical debt must be addressed and paid off, don’t let the corner-cutting of the past simply “transfer” the balance from one area of technical debt into another.
- Don’t “declare bankruptcy”. Again, Joel on Software argues against just deciding to rewrite the code from the ground up. Any argument made for this is equivalent to declaring bankruptcy – it’s deciding that the technical debt load is too high to ever pay off and we must eliminate it altogether. The problem is that technical debt doesn’t work like that. Old clients will still be using the old codebase. You’ll still have to support it. “Declaring bankruptcy” puts you into more debt from the moment you decide to do it because, for a while, you’re supporting two systems without being able to ship new features or iterations. This is bad. Don’t declare bankruptcy; it’s always easier to pay down your debts.
What’s your favorite technical debt tip? Tell us in the comments.
Frustrated with your company’s development practices?
You don't have to be!
No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist.
Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."