As a lead dev I have plenty of cases where I weigh effort vs impact and risk and conclude to “this is good enough for now”. Such cases are not poor management - which I assume you mean something like “we have to ship more faster, so do the shortest”. Sometimes cutting corners is the correct and good decision, sometimes the only feasible one, as long as you’re aware and weigh risks and consequences.
We, and specifically I, do plenty of improvements where possible and reasonable. Whatever I visit, depending on how much effort it is. But sometimes effort is too much to be resolvable or investable.
For context, I’m working on a project that has been running for 20 years.




























This is where I would have said “no, that’s not possible” or had a discussion about risks where things you simply can’t cover with automated metrics would lead to misdirection and possibly negative instead of positive consequences.
They then explore what technical debt is and notice that even many things outside of technical debt have significant impact you can’t ignore. I’m quite disappointed they don’t come back to their metrics task at all. How did they finish their task? Did they communicate and discuss all these broader concepts instead of implementing metrics?
There’s some metrics you can implement on code. Test coverage, complexity by various metrics, function body length, etc. But they only ever cover small aspects of technical debt. Consequently, they can’t be a foundation for (continuously) steering debt payment efforts for most positive effects.
I know my projects and can make a list of things and efforts and impacts and we can prioritize those. But I find the idea of (automated) metrics entirely inappropriate for observing or steering technical debt.