Attacking Technical Debt

I left for lunch on Monday shortly after sending one innocent little tweet: There was a problem connecting to Twitter.

The Learning

I received a lot of feedback and reference material from a number of different people here, here, here, here, and here. And I ended up learning a lot from this:

  • Everybody has a different definition of “technical debt”. It’s not your bugs. It’s not your backlog. It’s not your mess.
  • Learn from the experience. If this is an iterative process, this should be happening already, but knowing you are learning from the initial decisions you make helps to improve the decision making process during each iteration, allowing you to pay back some debt in each iteration or as you are learning more about what will work or not work or what you need or don’t need.
  • There is a common misconception of “technical debt” being “a mess” and Ward Cunningham clears this up in his YouTube video on the Debt Metaphor. When I sent this tweet, that actually was not specifically what I was referring to. I was referring to the work and non-revenue generating functionality that was cut or put off because we didn’t know enough to do it the best way the first time or it didn’t need to be. That stuff the user won’t see and likely won’t experience, but the stuff that makes easier to modify/extend, makes an application more compliant or follow established standards, able to take more traffic in the future. In my case, I don’t consider what we have a mess (others may argue with me on this one) because I do believe we made good decisions with what we knew at the time thinking we would magically get time to circle back before moving on to the ‘next big thing’.
  • Technical debt is incurred on an on-going basis. As we have to meet delivery dates and deliver in small iterations, we very often don’t know everything we need to know to make all the right decisions the first time out of the gate. So we must make some tradeoffs or incur some debt and this is on-going. For every project. We just need to continue making smart, educated decisions on these tradeoffs so that when we do circle back we can productively and effectively pay back the debt. In addition, we need to plan to address technical debt on an on-going basis. Just as you gradually pay back a loan, you have to gradually pay back the technical debt otherwise each future project will be impacted and probably not just by a factor of X.
  • There really is such thing as good technical debt. One article from this issue of Cutter IT Journal explains that debt for which the cost does not increase with each future project can be good debt to pay back over time.

The Plan of Attack

  • Give it some visibility: What is the list of tech debt items?
  • Put a cost to both paying back the debt and putting it off: What is the impact of doing it? What is the impact of not doing it? Now and six, nine, twelve months from now.
  • Plan for it in project work: There will always be technical debt for every project, so plan for it in estimates, costs, and timelines.
  • Don’t make a “mess” the first time through: Make educated, sound, technical decisions that will allow you to pay back the debt both productively and effectively when you do circle back.

For the record, I never found a “biz friendly term” and after all this, I’m not sure I need to find one.

So what is your plan of attack? What works for you?