Almost a month ago, my highly esteemed former colleague and the dotProject tech lead Adam Donnison asked an interesting question on his blog:
I'm often amused at the store people put in statistics. Forum post counts, bug counts, code commits, even lines of code are often touted as being indicative of some worth. The trouble is they are all very misleading. And what does it mean anyway?
When you're involved in a project of any size – Open Source or not – it's a question you have to consider. There are literally dozens of hundreds of articles on different ways of measuring someone's contributions:
Lines of code might work… but are you rewarding overly verbose or inefficient code?
Number of commits might work… but a single changeset could be a spelling fix or a small piece of functionality or an entirely new module.
Number of forum/mailing list posts… but being friendly or even unhelpful (or being in a flamewar) can skew this number without adding real value.
Number of bugs opened/resolved… but if you have/get numerous submissions of the same issues or someone dilligent in logging issues/requests
Documentation written… but this encourage the building and supporting of an unweildly or incomprehensible system.
Wow, so we have lots of bad ways of evaluating and comparing individual people's contributions, but none of them work out cleanly…
So what's the point?
There's another aspect and Adam hits it pretty clearly:
The worth of a programmer is something that is hard to quantify, but I guess it comes down to how your peers perceive you. After all, if you find that your peers enjoy working with you and respect you, what does it matter what some nefarious statistics show?
When you evauate team members, you need to look at all of the above. You need to see that their code is solid and useful. You need to make sure their commits are meaningful and hopefully granular to individual pieces of functionality or fixes. You need to encourage useful discussions and discourage flamewars. You need to rigorously scrub the bug system to make sure only actionable information is logged and kept. And most importantly, you should always strive to make the system bettter – faster, clearer, more useful – whatever your metric is.
Yes, any of these statistics individually can be manipulated and skewed but the underlying concept of "adding value to the project" is the key. Some of that is hiding in the above metrics, but the rest is completely intangible and can only be described by other team members, users, and the community as a whole.
And yes, this even applies to complete internal projects. 😉