Technical Debt – A Progress Killer!

Technical Debt
We Got 'Nuthin!

With any client that I work with, when we look under the hood at the current software that they have been building there has always been a crap-ton of code that has been passed over, saved for later, or just commented out. This does not include all the extra pieces of code that just sits around all over the place! One of the many issues that a development team must start to think about is how technical debt adds up.

Technical debt is anything that should have been done as part of a development process that did not get done. This includes Test Cases, bugs that were not resolved, un-refactored code, and missing documentation. This debt is like any other debt – you keep paying on it. By incurring this debt, the team, and systems are mortgaging our future.

  1. Technical debt slows down our velocity
  2. Technical debt causes more issues in the long run due to ‘work arounds.’
  3. Technical debt breaks processes and creates instability in releases
  4. Technical debt causes uncertainty

How do we fix it?

  1. Finish all bug remediation before launching because its 4x more expensive to do it after launch…
  2. Fix the process that allowed technical debt to get into the system in the first place
  3. Fix technical debt quickly or it will slowly bring down the system

How do we sell it to the business?

  1. Find a sustainable pace that does not incur technical debt


  1. Slow down velocity even more to fix the technical debt as part of the iterations

I prefer the second choice… but this is far harder to sell to the business unless they already have the understanding that we commit 20% of our time or more to fixing our technical debt and our development team has committed to fixing broken code.

[Image Source]

4 Replies to “Technical Debt – A Progress Killer!”

  1. Hi,
    I am not sure I agree that its one of the other in terms of choices.

    The first option – find a sustainable pace that does not incur technical debt, is about not creating new technical debt, but does not deal with the legacy TD created.
    The second option is about the resolution of legacy technical debt.

    so for me, you need both, double whammy!

    If its a hard sell to the business, then perhaps were selling the wrong thing. The business, when they are “there” will want this work done, will support the work being done etc…so if they are not on board and understand agile / lean principals, yes its going to be a hard one…so I would get them on the agile train first…


  2. Cuan,

    Thanks for the insight. You are absolutely correct. We need both a stable velocity and a customer/client who has bought in to it!
    Sometimes they can be tough though… they want what they want yesterday…

Leave a Reply