[theptip]

The big problem with this line of reasoning is that good developers hate working with bad developers. So if you don't do something about bad developers (which might just mean train them, not necessarily fire them), then the good developers will leave.

[lylejantzi3rd]

In that case, the bad developers are easy to spot. The good developers point right at them. There's no mystery nor are measurements needed.

[Jensson]

That is circle reasoning, if you know which developers are good so you can ask them then you already know which developers are bad.

And asking good developers to identify good developers doesn't work either. Good developers hates working with bad developers, true, but like all other humans they hate working with all sorts of people for different reason so they will point out a lot of good developers as well.

Instead what works is if you have lots of data from diverse group of good developers. That way the personal noise gets cancelled out and you are mostly left with the "I don't like bad developers" signal. This isn't trivial data to get though, especially since people usually choose to work with people like themselves so a team likely isn't diverse enough to get you this kind of data, and people from other teams aren't familiar enough to give good data either.

[pixl97]

You hire 5 developers.

3 of them point at 2 of them and say they are bad.

You fire 2 developers.

Nothing gets done. Turns out the 2 were the good developers.

Congratulations, you succeeded at making another bad metric.

[naasking]

That's just bad statistical analysis.