Ask HN: Data-driven tech debt investment

Have you seen companies that use some sort of organizationally mandated data-driven approach to deciding when to invest in tech debt reduction? What worked well about that? What didn't work?

I've talked to two engineers in the last few weeks who work at companies that:

1. Use a combination of per-team/service metrics to decide when to invest in paying down tech debt. For example: incidents/pages over a trailing window, DORA metrics, engineer ratings of the difficulty of working with the service, etc. 2. Enforce paying down tech debt for a team/serviceif those metrics go above a certain defined threshold. For example, teams with a high tech debt score at Company A are no longer allowed to develop new features. At Company B, high tech debt teams automatically get a tech debt-related OKR for the next quarter instead of a feature OKR.

In all my past roles, deciding to invest in tech debt was a judgement call and led to some significant frustration or even attrition when leadership and engineers didn't agree on how bad tech debt or ops pain was. It's exciting to imagine a better alternative, and both engineers I was talking to felt like it worked well at their company. However, I can also imagine ways it might not work well: Goodhart's law etc.

So HN, have you tried this sort of approach? Did it work?

3 points | by somuchdata 6 hours ago

1 comments

  • perrygeo 5 hours ago
    I haven't tried either of those two approaches but I have used this: If your upcoming feature work is impacted by tech debt, do the tech debt work first to set the stage for easier feature development.

    I've heard it called "make the change easy, then make the easy change".

    This has the benefit of putting all tech debt work in the context of moving the software forward. If there's tech debt in a corner of the project that never changes, so what? Leave it. If there's tech debt in an active part of the codebase, it quickly impacts feature work and needs to be dealt with immediately.