Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

Has anyone ever come across this problem? When you have a team of developers working on a project, how can you measure their contributions to said project? Is there a "formal" way of doing it? Number of commits? Number of bug fixes? Lines committed? Or maybe on a ticket basis?

I'm trying to think of a workflow where a group of developers can work seamlessly interchanging tasks and at the end of the month, getting paid for they contributions (or merit if you will).

I hope this question is not entirely out of place here, if it is, feel free to close it.

share|improve this question

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

marked as duplicate by gnat, MichaelT, Jalayn, Karl Bielefeldt, ChrisF Apr 10 '13 at 18:52

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.

Very difficult to do. Every project is different. I think it really comes down to how the project work is managed. Some teams are able to use agile or scrum tools to help measure progress. I've personally seen projects measure and display progress using – FireMouse Apr 10 '13 at 17:30

There's no way to accurately do this. For example, who contributes more: someone who commits 1000 lines of code in a month, or someone who spent most of his time thinking really hard, and then committing 100 lines of code that replace the 1000 lines of code? Or how about somebody that goofed off most of the month, then found those same 100 lines of code in a blog?

Who contributes more: someone who generated 100 image assets, or someone who spent weeks thinking about usability, and eventually checked in just a half dozen wireframes for a highly usable application?

In other words, how do you measure the amount of intangible work that most high performers do on a regular basis?

share|improve this answer
And yet, when we're part of that team, somehow we can tell who the high performers are. – thursdaysgeek Apr 10 '13 at 17:25
+1 for the intangibles. How about people who have social value, who make everyone more cheerful, and consequently more productive? How about people who always help out others when they're stuck on a bug? How do you measure that? – Avner Shahar-Kashtan Apr 10 '13 at 17:35
@thursday:Too bad that information frequently flies right over the head of management. – Dunk Apr 10 '13 at 18:52
@AvnerShahar-Kashtan - most definitely! I'm a decent plodder, but I do help others do better work. I recognize the high and low performers, but also can encourage better and happier work out of all of us, in a way that management would never be able to see, and certainly not quantify. – thursdaysgeek Apr 10 '13 at 22:41

I don't think you can do this, at least in the sense you suggest. Bryan's answer, and several answers in the question linked by gnat discuss several intangible (perhaps we should call them "immeasurable" in this context) productive activities.

Specifically, this:

I'm trying to think of a workflow where a group of developers can work seamlessly interchanging tasks

seems like it will set up a perverse incentive for the developers not to focus their efforts where they're most productive, but instead to pretend to be interchangeable resource units to fit your measurement scheme.

One approach would be to simply ask everyone to estimate everyone else's work, and average it into some kind of rough productivity consensus. This might just lead to (some) people talking up the complexity of their bugs or features around the water cooler though.

A more manageable way would be to just use peer reviews once or twice a year, where team members give ratings for each others' relative productivity.

  • because this isn't done every week, or per fixed number of stories, it's harder to game
  • because everyone on the team is already equipped with a large squishy computer which is carefully calibrated to assess group relationships, you can use these as a proxy
    • everyone knows the value of favours done or received, even if they're hard to quantify
    • if team members review each others' code, they'll have a feeling for who is storing up the most technical debt for the future
    • this allows developers to play to their strengths (ignoring personal development and team-building in this context, this should be the most productive)
share|improve this answer
And your suggestion won't be gamed either? I like my friends Bob and Jane so we'll be sure to give each other outstanding reviews whether they deserve them or not. – Dunk Apr 10 '13 at 18:55
"ask everyone to estimate everyone else's work... team members give ratings for each others' relative productivity" - that sounds like "360-degree feedback" assessment – gnat Apr 10 '13 at 19:03
@Dunk typically during performance review periods you'll be given the opportunity to ask who you want to give you a review but your managers will have the same option. They know what you've done through out the year and know under what other managers you've worked. It usually all ends up leveling out; you try to ensure your seen well and your managers try to ensure your seen honestly. If you're a good employee you'll get lots of people to say so and your manager will have the same results. If you're a bad employee few will speak up for you and your manager will get bad feedback. – Brad Apr 10 '13 at 20:13
I have worked at places with the 360 degree feedback practice as well as a number of other variations. 360 degree systems have their own set of issues. In particular, very seldom does anyone get a bad/mediocre review unless they are truly terrible. After all, you get to nominate who will review you, so you aren't going to pick someone that won't rate you good. And while your manager may or may not speak to a few of your team leaders/managers, many won't. If they do then the team leaders/managers opinion far outweighs everyone else's. So what's the point in doing the 360 to begin with. – Dunk Apr 10 '13 at 22:11
Also, my main point was that any system you come up with will be gamed. I just listed the most obvious way to game the above described system. – Dunk Apr 10 '13 at 22:12

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