[majormajor]

Most metrics measuring code are bad.

However, we have to try to come up with some. The idea that if you simply take away the metrics we will automatically improve the product is flawed.

Consider rewrites that burn a year of time for dubious value. Or fancy "refactors" that are really big heavy redesigns that lock you into abstractions that don't make sense in six months. Or devs that open 2000-line after 2000-line pull request...

At that point, code metrics aren't just about performance management, it's about me wanting to make sure I'm actually moving the code in the right direction.

Something I'm very interested in is if dev commit patterns line up with different types of work, and if some of those are "behavior smells" - e.g., not refactoring things one at a time, and getting your tests happy in between each move.

[urbanelask]

I'm not sure. If the majority of the metrics give a false or misleading sense of reality, then maybe taking away the metrics would be a net win. It's entirely plausible that the whole system of measurement we've come up with in this domain is fundamentally flawed and has more costs than benefits (see financial system risk ratings circa 2008). The skepticism of new metrics could very well be warranted until there's a real demonstration of success and good faith in their use.