27 ms·
> or of metrics that are just gamed (is test code coverage > 80%?) The rebuttal to your implied Goodhart's Law <https://en.wikipedia.org/wiki/Goodhart%27s_law
by mdaniel 3y ago
> or of metrics that are just gamed (is test code coverage > 80%?)
The rebuttal to your implied Goodhart's Law <https://en.wikipedia.org/wiki/Goodhart%27s_law https://en.wikipedia.org/wiki/Goodhart%27s_law> that was offered by my manager was "tension metrics" <https://en.wikiversity.org/wiki/IT_Service_Management/Continual_Service_Improvement#:~:text=tension%20metrics https://en.wikiversity.org/wiki/IT_Service_Management/Contin...>
If I understand his theory correctly, in your case there would be a competing metric to the "test coverage" one that said for any changeset, a test cannot itself change by more than 20% in the same changeset as non-test code. So you can change the code such that it still passes the existing tests, or you can change the test to adapt to new requirements, but you cannot rewrite the tests to match your newly changed code
I'm acutely aware this is a terrible example, the devil's in the details, and (in my experience) each company's metrics are designed to drive down their own organizational risk <https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law>, combined with "you're always fighting the last war" :-D
- marcosdumay 3y agoHum, now you are proposing a process checklist that can't ever be completely checked out, by design. The entire thing is terrible from principle. You won't find a good example, because that's not how you use a process checklist.