Post

In my experience, it's impossible to justify "paying down" tech debt to anyone outside your team's programmers, and even then it's iffy. Doing a bunch of work without changing the system is hard to quantify, perhaps even impossible. That said, cruft happens and needs to be dealt with. 2 strategies:

1 - Don't create cruft in the first place. Many devs think they must go as fast as possible (as opposed to fast enough) and just produce sloppy code. It's way better to just not do this, plus it's easier to manage a process that avoids. This relates to the second strategy

Using tools to help with changes (e.g. AI or scripts or whatever) is just a thing we have the help us with #1 and #2. I find it highly unlikely a team would have the capability and resources to do good work but somehow not be able to improve the codebase as they work. Clean as you go.

What if a mess already exists? TBH, my answer is too bad. Find a way to make small improvements over time as you work, or find a way to quantify in business, not moral, terms about why a larger improvement is needed.

And if you should get cover, time, and/or resources to undertake a major improvement: work you fucking ass off to finish it as quickly as you possibly can, because these types of projects are the top list to be cancelled to reclaim resources for shorter-term gains.