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:
Technical Debt – Don’t Let it Kill Your Projects
Gary’s Blog, Aug 2010
I also came across this article in MSDN magazine back in 2009 which was a must read for anyone involved in writing or managing a software solution:
Using Agile Techniques to Pay Back Technical Debt
MSDN Magazine, Dec 2009
If you don’t know what Agile Techniques are then you can read more about it on Wikipedia’s Agile page or just dive into the above article as it explains it part way through.
Another article that followed shortly after by the same author was:
9 Useful Tactics for Paying Back Technical Debt
MSDN Magazine, Jan 2010
I thought this topic worth addressing in a post as it’s something I come back to time and again when speaking to non-technical project stakeholders who don’t understand why it’s important not to rush the solution design or build process and consider the technical debt associated with both technical and non-technical decisions. Every system I’ve worked on in my career has been maintained in one way or another and when the technical debt aspect of a project is addressed before and during the development life-cycle it makes maintaining and upgrading the solution far cheaper, with respect to both time and money.