[kayo_20211030]

If "Cybersecurity Risk" were the only form of technical debt, we'd be just fine(?). Or, at least, we'd have some sort of metric. It wouldn't be a good one, but it'd be there. Chance of a breach: 1%. Existential or not? Probably not. Cost of mitigation? Probably small. Worth addressing? Mostly no, unless you're a regulated entity; then it's mandatory. Quantifiable, for this narrow case, but what of the rest?

[esafak]

Apply the same mentality to other things. If the cybersecurity folks can quantify risk so can you. Are you keeping track of your supply chain? How modular is your code? How easy to refactor is your code? You could think of reasonable metrics to measure various aspects of technical debt. It won't be perfect but it's better than nothing.

[recursivecaveat]

I think a bad metric is very much worse than nothing. It sucks away time to record, debate, report, and discuss. It encourages bad decision making. If you throw up a number people will give it weight, even if it's stupid. Multiplying 6 gut checks and trying to make a decision about engineering direction is like tracking someone's mood by the metric of whether they ate an odd or even number of calories yesterday. There's theoretically a signal under all that noise, but the direct gut-check or any number of qualitative clues are so much better than the distracting number.

[kayo_20211030]

I agree whole-heartedly. A bad metric is a curse. It's misleading, resulting in waste, and falsely reassuring simply because it exists as a number. +100 on the gut-check qualitative approach

[haskellandchill]

You can say whatever you want, there are studies backing up the beneficial impact of quantitative over qualitative.

[kayo_20211030]

They'd be quantitive studies of quality, I hope.