The best working definition of technical debt I know is “Work you purposefully put off now, knowing that doing so will create more work in the future“. That’s a bad thing, right? Well, not always. Creating technical debt can be like borrowing money; you know you will have to pay it back with interest in the future, but what you can do with the money today can be more valuable than the future cost. Similarly, getting that feature out the door in this release, knowing you have edge cases it won’t handle or a clunky implementation that will come back and bite you if not refactored soon, can be well worth it. It means being more agile, capturing market share sooner, and getting feedback from the customer sooner. Creating technical debt is sometimes necessary because “Perfection is the enemy of good” (or done).
Just like that loan, you have to pay it back, and generally speaking, the longer you wait the harder and more expensive it is to do so. This can be hard to do, because
- You have to remember it to fix it
- Just like defects. the longer they exist the harder it is to get back in that context and remember all the details
- That technical debt is competing for resources with shiny new work that people want to work on, and others want done