undefined | Better HN

0 pointsmajormajor5y ago0 comments

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.

0 comments

urbanelask5y ago

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.

j / k navigate · click thread line to collapse

0 pointsmajormajor5y ago0 comments

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.

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.

0 comments

urbanelask5y ago

j / k navigate · click thread line to collapse