SiteCrafting Blah Blah Blog
Dec. 21, 2007 at 10:19am
Technical Debt
What the heck am I talking about?
The concept of technical debt (first coined by Ward Cunningham) has been something that has wandered about my head without a name for quite some time. The other day I read an article that finally put it into words. It is what I have always seen as the reason writing beautiful code is not just an endeavor in aesthetics. At this point you're probably wondering what the heck I'm rambling on about. Don't give up on me yet, I'm about to explain . . .
For most developers, time is a commodity that is often scarce and very expensive for our employers. With a resource in such high demand, it is no surprise that there is a temptation to do what we can to conserve it. Certainly there is nothing wrong with being efficient, but there is also a point at which efficiency ends and technical debt begins. Technical debt is created when we start to write sloppy code, "hacks," or make other wreckless time-saving maneuvers. While we may save time in the immediate future, we are actually incurring a debt that will eventually have to be repaid, with interest.
The interest basically encompasses the extra time and effort we have to spend fixing bugs and making improvements as a result of the earlier shortcuts that were made. Just like financial debt, technical debt can be paid off. This is done through code rewrites and corrections to bring the quick-and-dirty code up to snuff. The longer we leave the debt unpaid, the more the interest grows until it ultimately can bring a development team to its knees.
Technical debt can actually be a useful tool, if handled responsibly. You can choose the quick-and-dirty route to save time and meet a deadline, and then later repay that debt by fixing the code afterwards. This way you can release planned functionality on-time and "save face" if you are developing software for a client or third party. Be weary of this practice though, while clients may only be concerned that something "works" they will also be the first ones to complain when something goes wrong and it takes you unusually long to fix it. Just like a credit card, this approach requires that you follow through with your obligation to repay your balance later.
So the next time you're deep into a project and you think "I could throw something together in 5 minutes and everything will work" don't forget that the 5 minutes you saved could cost you hours six months later when a client requests new features or bug fixes. Make sure it's a debt you are able and willing to repay.
Posted in Deep Thoughts, Software Engineering by Nick Williams
Comments (3)
Brian says:
As a good friend of mine once said to me, "If you don't have time to do it right the first time, how will you possibly have the time to do it over again."
1 | Dec. 21, 2007 at 5:22pm
The worst part of technical debt is when the creator of the debt is long gone and a new dev has to figure it out. This can really add to the time that it would have taken the original dev to fix it or just do correctly in the first place (in my experience the original dev will usually fail to comment their quick-and-dirty code). For people working in shops with high turnover this can be a major issue and usually will blow any estimates you originally gave the client when they come calling for changes or updates to their website/app.
2 | Left by scott | Dec. 27, 2007 at 11:09am
One of the more challenging aspects of technical debt is actually measuring it. You know just by looking at a hack that it is a bad thing, but how bad in practical terms is it really? I.e. how much in terms of time and effort is it costing the dev team to fix it or work around it? Us developers tend to be perfectionists at times, and we often have a bias against anything but the most beautiful and elegant code.
Measuring technical debt can be particularly important in the cases that scott talks about in his comment - the dev that came up with the hack/shortcut is long gone, and management wants a good reason to invest time in straightening things out other than just "it would be a nice thing to do".
I am working on a method to do just that - measure technical debt:
http://7thursdays.wordpress.com/2007/08/03/how-bad-is-your-architecture-measure-it-the-agile-way/
Check it out, you might find it useful in your endeavors to produce beautiful code and get management fully on-board in the process :-)
3 | Left by Chris Balavessov | Dec. 28, 2007 at 3:57pm