Developers productivity measurement

Question

Could someone point to some online resources about how to track developers productivity (tools, article and so on) or point to some article where it's debated that productivity of developers can be really measured? I've found some document and presentations from an old Gartner group CD but they are pretty old (2005), maybe in the years passes something has improved.

After seeing the answers some comment:

• I agree that LOC or function points are ineffective measurements
• I also agree that productivity is a difficult thing to measure

But problem is that in a big company management asks for hard data and you cannot always believe that managers are ex topgun programmers that once delivered Excel (Hi Joel!), so you need to come up with some measures. And it's very sad that in years of experience our discipline has never come up with good solutions about measuring the success of a project or to determine which development environment (talking about tools and languages, I do not want to talk about people!) is more productive, all we have to show to managers is some blog post with real experience or some research from "organization astronauts" that talks about measure development tasks without having ever written a line of code.

I was hoping to find some better solution, next week I'll try to let you know how our research has ended.

Answer 1

http://geekdoctor.blogspot.com/2008/01/measuring-programmer-productivity.html

Some interesting ideas

Answer 2

You give a developer a task, ask him/her to solve it and measure how long time it takes to solve the problem.

Micromanagement is evil. Measuring lines of code is useless, because less truly is more.

Answer 3

Only slightly newer (Sep 2006), but in the last 2 years you could argue Google's developers have been fairly productive:

Measuring Programmer Productivity (Youtube video / a Google Tech Talk presentation)

Answer 4

I assume you're asking because you realize lines of code, number of bugs fixed, and other metrics oversimplify things and can easily be gamed. If you've done enough design and broken the project out into manageable sub-tasks, measure how long it takes for the sub-tasks to be completed. But realize to compare how long it takes one developer to complete a given sub-task to how long it takes someone else to complete a different subtask is rarely fair.

Answer 5

Tracking individual productivity in software teams is a tough objective.

I mean, what kinds of tangible characteristics are you expecting to measure? Lines of code? Number of bugs? Frequency of clean builds?

You may have programmers that increase the productivity of your whole team while contributing less than the average developer. You may have a work environment that's lethal to programmer productivity.

Consider measuring their satisfaction with work in general. Do they have an adequate level of privacy? Do they feel encumbered by distractions?

If you'd like a human perspective on development teams, read Peopleware. It's a nice break from corporate performance metrics.

Answer 6

Really, honestly, you have to judge by not only the completion of work but also the quality. Peer reviews and realistic deadline and schedule meeting are what I feel are the best ways to judge a developer.

If the developer finishes their work on time or sooner and produces good, stable, maintainable code then they're doing it right. If not, you have a problem.

Answer 7

Follow an Agile Scrum methodology for your development

• Have daily morning meeting to check, What has accomplished yesterday and what is gonna do today
• Use VSTS(Or any good tracking tool) to assign Task and encourage developers to update their daily progress against each task. This gives an accurate productivity measure
• Give a great learning environment and freedom to experiment new things.

Answer 8

Developer productivity is really a qualitative measurement, not a quantitative one. If you reward developers by quantitative measurements (lines of code, number of bugs, time spent per project, etc.), you'll actually encourage them (consciously or subconsciously) to sacrifice quality and thus be less productive.

Look at the quality of their applications, the quality of their code, and so on. If you don't feel qualified to make these subjective judgments, consider getting feedback from others whom you trust including their developer peers.

Answer 9

Depending on your situation I think different measures are relevant but I don't believe their are best practices on what you are asking about.

I would suggest business value created if you are developing for a business. However, this would be difficult to measure.

Atlassian Fisheye has some code metrics built in.