What is the difference between this metric and unit testing? In other words, if you're just refactoring because you can, and the basic functionality you need from it still works, then is that time well spent? If it's truly broken then shouldn't your testing reveal that?
I am not familiar with metric testing, so I can't answer your first question. My bad.
Concerning refactoring, I see value in doing it, especially if it is results in the code doing exactly what it should be doing as before. If someone just refactors so they can pass the time, then I'd agree that's a waste of time and effort. But one of the goals of refactoring code is to make it adhere more to the SOLID principles. For example, I've seen lots of code in which a module is meant to do one thing, but when you look through the code you see that it's doing half a dozen or more things, as it accomplishes doing that one thing. That violates the "S" in SOLID (Single Responsibility Principle). So refactoring code like that will leave you with routines which do the one thing they're supposed to do and that one thing is only done by one routine, rather than being done by several routines scattered throughout the code.
"this metric" = technical debt. I was just wondering if there was really any value in trying to decide somewhat subjectively how "bad" existing code is, when you could use the mechanism of unit tests to determine if something was doing its job. Over time, as all the other unit tests are passing, you could add in things for quality checks like SOLID
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses