How to (and how not to) measure programmer productivity

Traditional methods don't suffice for measuring programmer productivity, but don't throw them out completely

Can programmer productivity be effectively measured? Blogger Jim Bird joins the chorus claiming that it can't – at least not using traditional methods alone:

There is no clear cut way to measure which programmers are doing a better or faster job, or to compare productivity across teams. We “know” who the stars on a team are, who we can depend on to deliver, and who is struggling. And we know if a team is kicking ass – or dragging their asses. But how do we prove it? How can we quantify it?

Bird quickly debunks lines of code as a measure of productivity, noting that the best programmers take the time and forethought to do more with less code. Likewise, many executives would measure productivity by the value of the end product; does it make or save the company money? This measure doesn't account for the myriad business factors that can help determine whether a product or service succeeds, however, regardless of the quality of input from the development team.

So what other measures are there? Bird offers a handful, tweaking each one for a more precise result:

  • Speed of development, or velocity: Velocity is intended to be used by a team to measure how much work they can take on, to calibrate their estimates and plan their work forward. It should not be used to compare productivity between teams, however, and it must account for changes in the team, as people join or leave.
  • Cycle time – or 'just stay busy': Measuring time to product (the turnaround time or change lead time for new product development and release) gives an overview of the team's productivity. Better yet, look for and optimize out the bottlenecks and idle time that contribute to longer turnarounds. This measure encourages short-term thinking and cutting corners, however, because speed equals reward.
  • Code quality: Fixing bugs later costs more than testing for them early and often in the development process, and there are many good ways to measure code quality. But does code quality directly correlate to developer productivity?

Read more on Jim Bird's Building Real Software blog, and get two more suggestions for measuring and improving developer productivity.

This story, "How to (and how not to) measure programmer productivity" was originally published by Java Everywhere.

Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.