I'd say if you're using quantitative metrics, you shouldn't go for number of bugs he's had. A senior developer will always have more bugs to his name than anyon

I'd say if you're using quantitative metrics, you shouldn't go for number of bugs he's had. A senior developer will always have more bugs to his name than anyone on a team because he's put more lines of code in. It would be better to do number of bugs per 1,000 lines of code. Even then it'll be relative, one person might have hundreds of single lines in their code, while another might do dense lines. I've seen this kind of stuff try to be deployed in the literary world and it always falls flat. One guy can say in 100 words what someone else wouldn't be capable of getting out in 10,000. Another might be writing 5 page features and the rest of his team are writing half-pages or less. Then there's creativity and personal voice. I'm sure there are thousands of developers out there, likely hundreds on HN who are very elegant coders. I'm sure there are many who aren't. People need to be judged on an equal playing field, if your metrics are bias you're going to be judging someone unfairly, and I don't think anyone here would want to go to trial over an unfair dismissal. A small company wouldn't survive losing to that. So my advice would be to be exceptionally careful in the ways you judge your workers and don't distance yourself from the judging. If you're relying on a computer to decide who is a good worker and who isn't, then you're in risky territory.