Is is fair to judge a developer's performance based on the number of bugs filed against his name? Don't do this! You will get disastrous results. For example,

Is is fair to judge a developer's performance based on the number of bugs filed against his name? Don't do this! You will get disastrous results. For example, some programmers have more bugs assigned to them because they care more about fixing things. People know this, so when they want something fixed they will try to assign it accordingly. If you only look at the metric, you won't be able to distinguish this case from a bad programmer who generates more bugs. It's well known that metrics like this don't work. The moment you settle on one, everybody will begin optimizing for that (instead of, say, getting their job done). This inevitably leads to unintended side-effects. Your best bet, assuming you're a manager who isn't working on the program directly, is to pay a lot of personal attention to what's happening on your team. Over time, you'll notice patterns. There is a related pitfall I've seen many people fall into: watch out for the case where someone looks like a star performer because he's cranking out shoddy work. This guy often becomes the manager's favorite because he seems to get features done quickly, when what's really happening is he's getting them half-done and making a mess in the process. Worse, truly good programmers then compensate by taking time to clean up this guy's messes, which makes them appear less productive. One bad programmer like this can easily suck up the value of half a dozen good ones. The solution is to make sure not to take things at face value, but to watch carefully to see what effects someone's work is having on the product and team as a whole. This is hard but doable; everything that's going on in the code is ultimately visible at the human level if you know how to read it.