We say we’re taking on technical debt when we compromise on software quality to meet a deadline.
Just like with real debt, sometimes taking on technical debt is the best thing to do in a given situation. Sometimes short term needs win.
But we need to be aware of this decision. We have to be conscious of the trade-offs involved and make an informed decision to take on the debt. We should think of the decision as a short-term move and actually intend to pay the debt back down as soon as possible.
Here’s a way to help with this: Every sprint, as a part of your review/retrospective/whatever, set aside time to discuss any technical debt you incurred to meet the sprint’s goals. (If you’re not doing sprints, you can still schedule this activity at intervals.)
Building tech debt review and tracking into your system will help you stay aware of it. Reminders to think about the debt become reminders to stay on top of it, to keep it paid down.
And if you’re not keeping track of your debt, maybe you shouldn’t be thinking of it as debt. Maybe you’re just making a mess.
