If you’ve ever had to maintain a piece of existing then you will have had some experience with technical debt. If not by name then you’ll certainly know of it if you’ve spent longer than you should refactoring or extending a system’s code base.
So what is technical debt? Well, imagine its Friday Afternoon, and it’s Check in Time. You cant go home until you’ve checked in your code, and you cant check it in until the last test passes. To get that test to pass you know you should re-architect the object hierarchy slightly, but you know that’s going to take a long time and there’s a cold beer waiting for you at home. So what do you do? You apply a quick fix, knowing you’re going to come back on Monday morning and fix it. We’ve all been there right? But how many of us remember to make that fix on the Monday morning? And that, dear reader, is technical debt. A little bit of code, just sitting there in the code base, gathering interest in the form of every subsequent piece of code that is build on top of it, or with which it has a dependency, just waiting for the day that debt has to be paid off.” – Gary Short, UK MSDN Flash eBook: Best Technical Articles # 2
Gary Short’s Blog does a great job of defining technical debt in his post: