Servicing Technical Debt

I’m heading to the Agile2009 conference next week, and looking forward to it.  It’s sort of fun watching the twitter chatter about the conference.  Some ads/pimping products and services, but also some of the conference presenters are talking about how they’re getting ready, and even posting their slides!

Someone retweeted this video from Ward Cunningham (yes, the one that invented the wiki) about the metaphor of ‘technical debt.’  Basically, when you are coding short term solutions that you know don’t completely address the core problem your code is designed to address, you are incurring ‘debt,’ similar to the way you incur debt when you borrow money.  Until you repay that debt, more and more of your effort will be consumed servicing the debt.  You’ll spend all your time patching holes, and won’t have any time to address new features or take on new projects.

This metaphor is directly applicable to one of my work projects.  It turns out that when we originally designed the system, we ‘missed’ a requirement.  After the product went live and business users started seeing it, they realized that there was something else it needed to do in order to align with their business rules and customer contracts.  Since then, we’ve had to build certain workarounds in order to address this discrepency.  Cunningham would argue we’ve incurred technical debt, which we need to repay by refactoring and revising our code in order to reflect our current understanding of the business processes. 

That refactoring/revising is a key part of Agile development.  We have a few challenges with that.  First, I don’t think we have enough unit test code coverage to be confident our refactoring doesn’t break anything.  Second, it’s difficult for us to find time to go back and fix things because all the new things people are asking us to do are piling up, and of course those are higher priority.  I think agile people would say we need a Kanban process.  Third, the powers-that-be don’t see the value in going back in reorganizing something that ‘works,’ so it’s hard to argue for the need to service our technical debt.

I’m hoping to learn more about how to address these challenges at the conference.