To Stop Cheating, Nuclear Officers Ditch the Grades

In other words, you get what you measure. This is one of the reasons I discourage measuring team performance in terms of bug counts or lines-of-code. The former lead to what some call "issue-tennis" and informal fixes, and the latter lead to code bloat. After years of trying, I've finally concluded that "key performance indicators" attached to individuals or teams (as opposed to artifacts and periods) usually leads to more trouble than they're worth.

Re: To Stop Cheating, Nuclear Officers Ditch the Grades

#5

Post by jedberg » Tue, Jul 29, 2014, 7:34 AM UTC

So War Games was right then... We really do need to replace the officers with computers.

Re: To Stop Cheating, Nuclear Officers Ditch the Grades

#6

Post by mkesper » Tue, Jul 29, 2014, 7:37 AM UTC

The world could sleep better if those fatal missiles worldwide had a delay of 24 hours, at least.

Re: To Stop Cheating, Nuclear Officers Ditch the Grades

#7

Post by WalterBright » Tue, Jul 29, 2014, 7:51 AM UTC

hliyan wrote: post #4

In other words, you get what you measure. This is one of the reasons I discourage measuring team performance in terms of bug counts or lines-of-code. The former lead to what some call "issue-tennis" and informal fixes, and the latter lead to code bloat. After years of trying, I've finally concluded that "key performance indicators" attached to individuals or teams (as opposed to artifacts and periods) usually leads t…

I learned that 30 years ago. It seems to be one of those things that every generation needs to learn the hard way.

A reason why an effective team needs a few older guys who've been around the block a few times :-)

Re: To Stop Cheating, Nuclear Officers Ditch the Grades

#8

Post by lobotryas » Tue, Jul 29, 2014, 7:55 AM UTC

WalterBright wrote: post #7

hliyan wrote: post #4

In other words, you get what you measure. This is one of the reasons I discourage measuring team performance in terms of bug counts or lines-of-code. The former lead to what some call "issue-tennis" and informal fixes, and the latter lead to code bloat. After years of trying, I've finally concluded that "key performance indicators" attached to individuals or teams (as opposed to artifacts and periods) usually leads t…

I learned that 30 years ago. It seems to be one of those things that every generation needs to learn the hard way. A reason why an effective team needs a few older guys who've been around the block a few times :-)

True. Unfortunately you then get a new VP who still believes in KPIs (or needs to demonstrate KPIs to his boss because that's the only thing upper management "gets") and then you're back to square one :(

Re: To Stop Cheating, Nuclear Officers Ditch the Grades

#9

Post by teddyh » Tue, Jul 29, 2014, 7:59 AM UTC

thisjepisje wrote: post #3

Classical example of Goodhart's law: http://en.wikipedia.org/wiki/Goodhart%27s_law

I would think that Campbell’s law is a slightly better fit:

https://en.wikipedia.org/wiki/Campbell%27s_law

Re: To Stop Cheating, Nuclear Officers Ditch the Grades

#10

Post by Ntrails » Tue, Jul 29, 2014, 8:52 AM UTC

hliyan wrote: post #4

In other words, you get what you measure. This is one of the reasons I discourage measuring team performance in terms of bug counts or lines-of-code. The former lead to what some call "issue-tennis" and informal fixes, and the latter lead to code bloat. After years of trying, I've finally concluded that "key performance indicators" attached to individuals or teams (as opposed to artifacts and periods) usually leads t…

If the KPIs were, say, something to be minimised - does this still hold? For example, I cannot see a way to game "Lower system downtime is better", or "lower load time is better". Or am I fundamentally misunderstanding what a KPI is?