What are suitable performance indicators for programmers?

Question

Hi,

I am wondering what performance indicators people encounter, and think are realistic, for programmers in the workplace?

I've seen numerous articles (I can't recall a really good one that I read right now) that detail how programmers will optimise for the metric they are being measured by (whether that be lines of code etc.).

However, is there any metric that can be used as a good performance indicator of a programmer in the workplace, and conversely be used as a milestone by a programmer when negotiating with management?

Replies Thanks for the link to that one and good feedback so far!

Answer 1

1. Good quality code as verified at code reviews
2. Low bug count
3. Product shipped on time
4. Interacts well and shares knowledge with team

Answer 2

Tips For a Software Engineer Performance Review

Answer 3

The only performance metric I think is important is how well you meet your task estimates and the quality of your work.

If you have a programmer who is consistently meeting deadlines and has minimal implementation bugs and a well-tested and documented solution then that is a good performance indicator.

Lines of code, for instance, is a horrific indicator. I think you can only really judge performance on the time-scale of whole features rather than individual days.

Answer 4

I measure performance of a developer via his/her "rebounds". So, wtf is rebound? It is jobs which the developer says 'done' for them and then come himself/herself back after a while. More rebounds, more risk.

Answer 5

In the Agile/Scrum space there is the Velocity metric which determines how many story points you've completed per iteration. It you commit to fixing bugs as they appear you can then get an semi accurate metric.

Even though you are offsetting the time spent fixing bugs to the next iteration you will get an average going over a few iterations. Another good approach is to put all the setup tasks up front (setting up source control, automated builds, CI etc) into an iteration 0 so you are just measuring time spent on development. This will be skewed by varying resources and holiday time though.

Answer 6

It's really hard to measure. Martin Fowler even says it can't be done: Cannot Measure Productivity

Answer 7

Once you've been in this game for a while, normally it's stinking obvious in a short space of time whether someone is up to scratch. But hard to quantify. Before it even gets to the point of trying to measure producitivity, the simple FizzBuzz interview question seems to weed out most dead beats

Answer 8

I think this can only ever be a subjective measure.

Any metrics you apply will be either misleading or subject to "gaming".

Even something as simple as "number of bugs" can be misleading, what if you are accessing a poorly documented legacy database? Even the best programmer will encounter a lot of bugs in these circumstances.

Answer 9

I'd propose a similar thing to aksangrav's rebound concept. But it's not if they go back to work after saying it's done, but how often I (or the code reviewer) find non-trivial issues in work they mark as complete. e.g if a code review finds code that doesn't compile or crashes on a simple case, that's a BIG warning. Small things that anyone can make, or persistent failure to meet coding standards count a little as well, because you sometimes will find developers who can commit near-perfect code nearly all the time and you want them to be differentiated from the merely 'competent' people.