How do you choose when to pay for technical debt?

Questions
1

I’ve recently joined a project and been going through the challenge of understanding when to enter the rabbit holes of technical debt.

A few questions I keep asking myself when choosing when to pay for tech debt:

  • Is it mandatory?

  • Is it a side quest or a step of the current path?

  • How much will it break things if you make a mistake?

  • Can it cause regression?

  • Is it S, M, L, or XL?

  • Is the increment better than what we had before?

  • Is it worth it? Is the result > the cost?

I’m trying to push improvements incrementally. Taking baby steps.

When needed, I’m extracting reusables from repeating elements. Making sure they work on all instances. Making sure I’m not breaking anything else. Often creating new styles and upgrading UI in a sustainable way.

But do you have questions you ask yourselves or a procedure you follow to make these decisions? Any tips?

2 Likes
2

You’re right on track with your questions about incremental improvements and avoiding breakage — that’s the essence of sustainable refactoring.

Here’s how I typically decide whether to tackle technical debt:

  • Is it an immediate blocker? If the debt is directly hindering the feature I’m building, I’ll fix it then and there. It’s pointless to build new features on a shaky foundation.
  • How frequently does it cause issues? A problem that impacts the team every sprint is a higher priority than a rare corner case.
  • Will it create future value? Some debt compounds like interest. If addressing it now will accelerate or improve future work, I lean towards tackling it sooner.
  • What’s the potential impact of fixing it? If touching the code risks widespread regressions, I’ll either allocate extra time for testing or postpone the fix until we can dedicate more attention to it.
  • Am I already working in that area? Often, debt gets cleaned up simply because you’re already in that part of the codebase. It’s more efficient to fix it when the context is fresh than to create a separate task for it later.

Like you, I also consider effort versus payoff, and t-shirt sizing is excellent for this. A “small” cleanup with significant benefits is usually a no-brainer, whereas an “XL” rewrite requires a compelling justification.

One additional helpful tip: cataloging technical debt. Even if you don’t fix it immediately, logging it with context transforms “gut feelings” into something you can prioritize during planning, avoiding on-the-spot decisions.

For instance, on a recent project, we repeatedly encountered a date/time utility that was set up horribly and led to subtle bugs or workarounds across a few features. Rewriting it wasn’t on our roadmap, but since virtually every new ticket involved that code, we spent half a day+ refactoring it.

I’m curious if others have frameworks or rules of thumb that extend beyond gut checks – I’m always looking to refine my approach.

1 Like
3

Cataloging is something I can definitely add to my list.