KPI's for Programmers

Question

Do you know any Key Performance Indicators for Developers? What should be measured and monitored?

Answer 1

Consider the following truth: you will get exactly what you measure and monitor. With that in mind:

Terrible things to measure

Lines of code - Elegant code has a concise nature to it. Lines of code encourages bloat, copy and paste, or even worse, code for the sake of code.

Time-to-solution - Code done quickly contains lots of bugs.

Bug fixes - This goes with 'time to solution'. Don't reward programmers for writing slopping code, and especially don't reward them for fixing the problems they caused in the first place!

What, IMHO, you should measure

Impact. The only thing that matters is what your developers do. Did you write a tool that improves efficiency by 10%? What about automating a task that used to take 3 hours? What about refactoring that gnarly library so it is now easier to use for everyone on the team?

You should measure what happens after code has been written, and how valuable the contribution is towards your business/company's goals. Note it is possible to have a negative impact.

Answer 2

Which door represents your code? Which door represents your team or your company? Why are we in that room? Is this just a normal code review or have we found a stream of horrible problems shortly after going live? Are we debugging in a panic, poring over code that we thought worked? Are customers leaving in droves and managers breathing down our necks..

(Robert C Martin, Clean Code - book that opens with above picture)

Answer 3

Assuming you've hired someone smart, they should be getting things done. Beyond that, when you measure employees (especially programmers), you get exactly what you measure.

In short, monitor that projects are getting done within the standards of the team.

Answer 4

How about efficiency (work done/hr)?. This can be measured with the pomodoro technique. Take a look at this presentation.

Once you are tracking your pomodoro estimations and the actual executed pomodoros per task, you can then measure the reality factor, which this tool called pomodairo does for you. This reality factor can sum up how good are your estimates and how efficient you are; for evaluating efficiency I'd stick to no more than 2 pomodoro tasks.

I find pomodoros objective (on an individual basis) because each one mean a fixed ammount of focused work and they are a good measure for you to improve, which IMHO is the real purpose of any metric of these sorts that matters.

Answer 5

We just went through this at my work. Trying to figure out what our KPIs should be, and then what our KPIs were going to be (since they turned out to be hard to measure).

THE KPI should be a measure of solving the business requirements in a timely fashion. If someone knows a good way to measure this let me know. :)

We ended deciding to use # of features implemented. Our customers sign off on every user facing feature and they are publicly prioritized (so people can fight for theirs to go first). We figured that was going to be a simple way to measure if we are performing well. We will see.....

Answer 6

There are almost no business metrics that you can use. You have to treat the programmer as a mathematician or scientist. The only thing that's measured there is the impact or potential impact of the ideas/code. Would you count the number of lines in a proof written a mathematician?

Even if you do use a measurement, it will be treated as an optimization problem by the programmer depending on if it determines their wages. Another point is that programmer productivity varies from day to day, some days there's a lot of lines of code written, other times no new design ideas are thought of, etc.

What are some of the key performance indicators for an executive or manager? Maybe you should try using those for programmers since we also deal with ideas and thought-stuff.

Answer 7

For an industrial programmer, $/hr saved (or earned) is, in my opinion, the only meaningful business metric.

Software types are notorious for having a gaming mindset (computer games, pen and paper, puzzles, etc). Don't incentive behavior that is not aligned with the business needs.

E.g., if you consider kLOC/week to be the key indicator, you're going to observe that for the same feature, you're getting many more kLOC.

Example:

int foo() {
   return blah;
}

Can well be turned into:

int
foo()
{
   return 
      blah;
}

For the same feature. That's a 2x LOC increase. If you rank my productivity primarily based on LOC, you better believe I'm going to evaluate whether I want to get that productivity-based bonus/promotion.

Answer 8

I would say that you need to align metrics from the business units to the programming. Programmers don't want that because they feel the business unit will screw up and they won't look good.

My answer is: Dude--or Dudette--work with your business users and make awesome tools for them that will make them ultra productive and their success will be your success.