Technical Debt: The Good, The Bad, and The Ugly

The best working definition of technical debt I know is “Work you purposefully put off now, knowing that doing so will create more work in the future“. That’s a bad thing, right? Well, not always. Creating technical debt can be like borrowing money; you know you will have to pay it back with interest in the future, but what you can do with the money today can be more valuable than the future cost. Similarly, getting that feature out the door in this release, knowing you have edge cases it won’t handle or a clunky implementation that will come back and bite you if not refactored soon, can be well worth it. It means being more agile, capturing market share sooner, and getting feedback from the customer sooner. Creating technical debt is sometimes necessary because “Perfection is the enemy of good” (or done).

Just like that loan, you have to pay it back, and generally speaking, the longer you wait the harder and more expensive it is to do so. This can be hard to do, because

  • You have to remember it to fix it
  • Just like defects. the longer they exist the harder it is to get back in that context and remember all the details
  • That technical debt is competing for resources with shiny new work that people want to work on, and others want done

I have found that the the most powerful thing you can do to make technical debt more manageable is to accurately and transparently track it. Make sure you have a record of

  • What the technical debt is all about
  • Why it was made and by whom (not for blame, but for context)
  • The cost of delay of addressing the technical debt

The obvious reason for doing so is that you can’t fix what you don’t remember. There’s another important reason to track technical debt transparently, and that is to use that documentation as a selling point for dedicating resources towards tackling it. With it, you can make higher ups, Project Managers, Product Owners, Finance/Legal, and even customers, your advocates for taking care of the technical debt by having something to point to and prioritize. You can discuss the value of addressing a piece of technical debt over taking on new work in a cooperative way rather than sneaking it in or demanding.

One last point I want to make is that “work” here is purposefully used in very generic terms. That “work” could be making decisions, making staff changes, knowledge transfer, building tools that will aide in production, or even establishing policies and working agreements. All of this applies to other fields besides software, and I purposely stayed away from software-specific terms for that reason.

What are your favorite tips and techniques for managing technical debt? Please let me know in the comments.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.