I would like to measure performance of my developers using KPI (Key Performance Indicators). Which KPI would best help me distinguish between good and "needs improvement" programmers?

  • 15
    I'm not convinced software development, at the level of the individual, has meaningful KPI in a general sense.
    – Ben Brocka
    Commented Mar 31, 2012 at 14:31
  • 3
    I think Bryan Oakley said it best in his answer. You are much better off trying to be an active member of your team than you are trying to pass judgement based on what you see in a spreadsheet.
    – jmort253
    Commented Apr 1, 2012 at 3:08
  • 3
    Try it for "a team" and you'll probably be more successful :)
    – PhD
    Commented Apr 2, 2012 at 5:07

6 Answers 6


For any measurement you use, programmers will figure out how to game it. The only true measure is whether they are delivering quality software on time.

I think you're better off just being an active part of the team. Don't rely on numbers, rely on actual observation of how they perform, perhaps combined with comments from their peers. If you have a well functioning team, it should be obvious which are the high performers and which need improvement.

  • 1
    "Quality software" is a subjective term. Can on time delivery be used as KPI?
    – meetpd
    Commented Mar 31, 2012 at 14:10
  • 6
    On time delivery can be used, as long as they are the ones deciding what "on time" means. You can't just stick a date on the board and say it must be done on that day. And yes, "quality software" is subjective. All measurement of productivity in a creative field must be subjective. They aren't making cupcakes -- you can't measure them by any particular quantity. Commented Mar 31, 2012 at 14:14
  • 2
    +1 "They aren't making cupcakes". great analogy. Although even cupcakes can be subjective if they're made by hand. Taste varies from person to person, and the designs in the frosting and the colors used, the creativity, is also subjective.
    – jmort253
    Commented Apr 1, 2012 at 3:01
  • Above links are broken.
    – codah
    Commented Sep 21, 2018 at 3:41
  • @codah: thanks. Apparently those questions got closed and deleted. sigh. Commented Sep 21, 2018 at 4:28

Over the course of a year, how many times did another team member ask this person for help, get it, and still was not afraid to come back and ask for help again?

Over the course of a year, how many features did this team member ship, to customers, that are used and were relatively free of bugs?

During the last live site incident, how did this person respond? Whether or not this person was the cause of the incident.

Regardless of your current team size, if you had a team of three, would you want this person to be one of them?

Every year when I'm asked for input on my peers, this is my personal checklist for completing that open-ended space on the form for "any other comments."


This is a hard one. You shouldn't really rely on raw stats (as others have said), and relying on things like lines of code, number of bugs etc, don't really give the fully picture.

If they are assigned specific pieces of work, I would measure productivity based upon whether they are delivering work according to client expectations (100% done, not 70% etc), and contributing to the work of the team as a whole.

You can, of course, also measure sickness levels, timekeeping etc, but that's a slightly different matter.


I would add one more indicator: time estimated vs time needed to accomplish a task. Having this data shows "reliability" of programmers and vastly improves planning. After couple of months you will probably see some patterns regarding people or type of tasks.

  • 1
    This just shows if the programmer is good at estimating, and/or whether they mostly work on predictable parts of the system.
    – Erik
    Commented Sep 21, 2018 at 4:36
  • @Erik it can, but there are risk-based estimation processes that can become very good at estimating innovation targets Commented Sep 21, 2018 at 16:29

I think the other answers have neglected an important part of your question:

"...distinguish between good and "needs improvement" programmers?"

I concur with the other answers that there may be better ways to look at this problem.

  • All known programmers need improvement. This isn't a binary "good" vs "needs improvement". The challenge here is to match the right opportunity to the right individual. I think KPI would be a bad fit for this; KPI are impersonal and standards oriented, and what you should be seeking is something very individual. One programmer may need to flex his skills in a new language/framework/environment. Another may need exposure to more database code. A third may need training in how to refactor their own code, while a fourth may just need some tandem time to practice coding to the team standards. My experience is that few people are comfortable asking for what they need; you're going to have to listen to them and to their teammates over time.

  • If you're trying to distinguish between the adequate team member and the team member who may need a performance plan, KPI will not help. (or by the time KPI reveals a result, you'll probably have dealt damage to your team that cannot be recovered. This is a John Galt solution). Listening to the team, spotting patterns of late delivery/quality problems, etc. will spot this.

Take "programming" out of the mix. If you were supervising construction workers or cooks, or circus performers or ... you'd be constantly looking at everyone's performance, looking for where they best fit on the next project, and for opportunities to improve that individual with training/coaching/whatever.

As others have said better than I, KPI are designed to detect whether you need to intervene on the project, to refine your confidence that the project will be delivered on time, to measure and predict performance at a team/deliverable level. Distinguishing between the individual who urgently needs improvement, the adequate performer who could be exceptional with intervention and the excellent programmer who you need to train to retain is a soft skill involving leadership and listening, and I'm not convinced that KPI is the ideal tool to support those activities.

Apologies if I'm stating the obvious.


Software development is tasks based and these are tagged to a deliverable schedule with Q A, Testing and UAT. All these are variables you can use to set the measurements of performance per developer.

  • 2
    we should leave this up, with downvotes, as an example of a bad answer. Commented Sep 21, 2018 at 16:30
  • @NewAlexandria did you have to throw that much shade? 😂
    – TheLebDev
    Commented Jul 5, 2021 at 14:03
  • @TheLebDev Chiaroscuro allows that shade make the light brighter Commented Jul 10, 2021 at 12:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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