One thing i struggle with is how to measure the job performance for software developers during their annual reviews. I want them to have specific goals they can work towards achieving and be able to see their progress throughout the year and celebrate their individual successes. Most of the goals for developers seem to be related to completing a specific project, but i am looking for individual metrics others use, thanks!
A:
Where I work at the moment they have a fairly in-depth project tracking system set up which (loosely) monitors hours and breaks down the amount of time we spend on developing new features/enhancements, bug fixes and support tasks. Hours aren't taken too seriously in performance reviews as multiple people working on one task will result in one of those people having hours recorded against their work history, but they do pay attention to the amount of time spent on each type of task. Ideally we're supposed to spend <=10% on support and <=20% on bug fixes. Arbitrary targets, hooray...
We have releases to production each Tuesday, and responsibility for who "owns" the release rotates each week. Rather than individuals being held accountable or measured against every little bug or breaking code they contribute, we tend to be measured more on how well each release goes. If a release causes breaking issues in production (or worse, requires an emergency rollback), it's the responsibility of release 'owner' regardless of whose code caused the issue. It tends to work well and be a lot fairer in practice than it sounds.
A co-worker was recently telling us about his previous employer where a new manager came in and introduced the concept of lines-of-code-per-day as a performance metric. As a result, they lost more than half of their development team within 3 months of him starting and the code being checked in was becoming increasingly long-winded and overly commented.
FerretallicA
2010-10-06 23:51:01