Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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

share|improve this question
19  
When you start measuring metrics, you get people aiming to maximize your metrics, instead of actually maximizing their productivity. If you hire good people, they'll get work done; if you hire bad people, metrics won't help as much as you'd like. –  Anon. Jan 6 '11 at 3:55
1  
Even good people need to know what is important though. For example, is keeping the site up 24/7 more important than new features? What about customer-support? There will always be more to do than your devs have time :) –  Chris Smith Jan 6 '11 at 4:11
8  
"Not everything that can be counted counts, and not everything that counts can be counted." - Albert Einstein –  Jason Baker Jan 6 '11 at 9:36
2  
There's this classic dilbert cartoon (dilbert.com/strips/comic/1995-11-13) that shows the risks with measuring and rewarding in the wrong manner. –  RobM Jan 6 '11 at 11:51
3  
The basic problem with using KPI's for programmers is that's assuming programmers are like engineers when they are infact more like artists/craftsmen. It's like having KPI's for Michelango painting the sixtine chapell. "10 brushstrokes per minute, excellent!" –  konrad Jan 6 '11 at 21:16
show 7 more comments

marked as duplicate by MichaelT, GlenH7, Kilian Foth, BЈовић, gnat May 19 '13 at 16:07

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

8 Answers

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.

share|improve this answer
3  
I actually worked for a PHB once who used time estimates to fix bugs as a measure (along with the time taken on development work as well of course) of productivity. Try explaining to someone like that how a 2-line bug fix might have taken all day to track down. –  Bobby Tables Jan 6 '11 at 6:12
2  
+1 I love the first line. Reminds me of a quote from this article (and it's The Daily WTF, so let that set the tone): "When you require developers write more unit tests, you get exactly what you ask for: more unit tests." –  Jonathan Hobbs Jan 6 '11 at 6:42
    
+1 yeah ! Stop taking developers for cogs –  user2567 Jan 6 '11 at 8:12
add comment

http://i.stack.imgur.com/a0bTh.jpg

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)

share|improve this answer
3  
+1. We had a discussion along these lines at my work a couple of years ago: the more comments in the code along the lines of "this is a horrible hack that I have to do because of X", the more productive that developer is. It generally means that they're working on real stuff which integrates with other stuff and often forces them into not being able to do things nicely. Hmmm, it's a bit of a you-had-to-be-there now that I think of it. But basically if you had no frustrations that led to such comments in your code on that team, it meant you weren't doing much (or didn't recognise the badness). –  Bobby Tables Jan 6 '11 at 6:19
2  
It's ok IMO to do ugly hacks to go quickly forward, on the condition that you continually go back and refactor them as appropriate, 3 steps forward, 1 step backward :) –  konrad Jan 6 '11 at 6:27
    
It's too bad that a lot of the time "going back" never happens. –  Jeremy Heiler Jan 7 '11 at 17:48
add comment

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.

share|improve this answer
    
Define Standards of the Team beyond what management dictates. –  Christopher Mahan Jan 7 '11 at 21:58
add comment

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.

share|improve this answer
    
This would not be a good way to measure productivity, though. For example, under Pomodoro, you're supposed to discard your current pomodoro if you get interrupted. Going to help a coworker shouldn't mean that I'm screwing up my own productivity numbers on paper. –  Anna Lear Jan 7 '11 at 16:08
1  
Huh? All this measures is the accuracy of your estimation. –  Tom Anderson Jan 7 '11 at 22:05
    
@AnnaLear You can always make smaller pomodoros if your position requires frequent collaboration. –  dukeofgaming Dec 31 '11 at 0:11
add comment

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.....

share|improve this answer
    
You've got a great start to answering your own question here: a measure of solving the business requirements. So how do you go from defining the requirements to running a system that meets those requirements? –  Huperniketes Jan 7 '11 at 13:11
    
Sounds like a strong incentive to break each "feature" down into pieces as small as possible! –  Highly Irregular Jul 3 '13 at 21:23
add comment

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.

share|improve this answer
1  
Not if you pipe it all through indent. –  Xepoch Jan 7 '11 at 18:49
2  
@Xepoch - believe me when I tell you - there's more than one way to skin that cat, and lots of them won't be affected by a run through indent. The point is: measure KLOC, you'll get more KLOC, not more solved problems. –  Michael Kohne Oct 1 '12 at 17:59
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.