3 ms·

Quantitative metrics typically fail. For example, the number of bugs would be expected to increase as the developer writes more code, so while one developer mig

by lrm242 17y ago

Quantitative metrics typically fail. For example, the number of bugs would be expected to increase as the developer writes more code, so while one developer might have more bugs assigned to him, that doesn't mean he writes worse code than another developer. The best answer is: you judge the performance of a developer the same way you would judge the performance of any employee. You gather feedback and apply your own personal assessment of that individual's performance given the tasks and objectives you've assigned. There is no magic bullet.

russell 17y ago
"Quantitative metrics typically fail." Tattoo this on your forehead so that you se it every morning. If you punish bugs, people are going to stop reporting them against themselves or their teammates. I often report bugs against myself so that I have a record more durable than a sticky note. Another demotivator is management hysteria to get the bug count to zero. Bugs need to be reported no matter what the goal is. The best way to understand what is is going on is to talk to people informally (definitely not regularly scheduled meetings).
electromagnetic 17y ago
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.

by lrm242 17y ago

russell 17y ago

"Quantitative metrics typically fail." Tattoo this on your forehead so that you se it every morning. If you punish bugs, people are going to stop reporting them against themselves or their teammates. I often report bugs against myself so that I have a record more durable than a sticky note. Another demotivator is management hysteria to get the bug count to zero. Bugs need to be reported no matter what the goal is. The best way to understand what is is going on is to talk to people informally (definitely not regularly scheduled meetings).

electromagnetic 17y ago

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.