Hello everyone,
    Out of everything I have ever been charged to do by my employer none have seemed as daunting as this: Create a Productivity Requirement for Programming based positions.

  I know that it is extremely hard to qunatifiy a programmers productivity so I am not really looking for an "answer" to this but am kind of curious as to how this is done in other agencies or past expereience people have had with this.

Discuss. ^^

================================================== =========
Read this if you want to know how to get a correct reply for your question:
http://www.catb.org/~esr/faqs/smart-questions.html
^^Took that from planoie's profile^^
^^Modified text taken from gbianchi profile^^
================================================== =========
Technical Editor for: Professional Search Engine Optimization with ASP.NET
http://www.wiley.com/WileyCDA/WileyT...470131470.html
================================================== =========
Why can't Programmers, program??
http://www.codinghorror.com/blog/archives/000781.html
================================================== =========

__________________
===============================================
Doug Parsons
Wrox online library: Wrox Books 24 x 7
Did someone here help you? Click on their post!
"Easy is the path to wisdom for those not blinded by themselves."
===============================================

Sorry for not picking up this thread earlier.

First of all, it is my opinion that this sort of evaluation is very hard to do in any fair manner, and will be counter productive.

Second, unless your company keeps extensive metrics, has a large enough base to be able to do realistic metrics (at least a few hundred developers), and understands how to interpret those metrics in meaningful manner, it will be difficult to do anything of value with a "Productivity Requirement".

Industry studies I have seen have shown that programmer productivity ranges a great deal, and it is not uncommon in an organization that there is a 10 times variation amoung developers at the same job level. That is a large variation! To gather enough information to make a measurement like this must be a monumental task.

I would suggest that it is much more valuable to evaluate developers on a team level. A properly built and mentored team should be rewarded as a team. As far as I have learned from reading and personal experience, when people must work in a team environment (which is the only useful structure for typical development projects IMHO) it is harmful to the team effort to evaluate team members individually. A team is either productive or it is not, and individuals on the team are either helping the team or they are not. When an individual is rated on the value of their own work, then they will potentially sacrafice the work of the team - for example, a good team member will want to help other team members so that the team is successful if they are rewareded for the team being successful, but if they are judged on their own output, then they will stop helping others and work only on the things they are being rated on.

Of course, there are a number of variables in this process, but I'm sure you understand my main point. We can see this in sports, as an example. If a soccer player is paid based only on how many goals he makes, then even the goalie will be trying to make goals. It is easy to see that won't work. It takes a team of players working together (and being "evaluated" together) to make a team that can actually win games. In this case, the evaluation is in games won, not in goals scored. In software development, the goal is the delivery of working code that has been tested to be correct.


Woody Z
http://www.learntoprogramnow.com
How to use a forum to help solve problems