Re: (OT) Proving Productivity?

[gmax]

Measurement is evil. It is difficult to implement and whatever you do to enforce a measurement policy you can end up with some unpleasant side effects.

I agree with Joel Spolsky's article that most measurement practice are counter productive.

Software organizations tend to reward programmers who (a) write lots of code and (b) fix lots of bugs. The best way to get ahead in an organization like this is to check in lots of buggy code and fix it all, rather than taking the extra time to get it right in the first place. When you try to fix this problem by penalizing programmers for creating bugs, you create a perverse incentive for them to hide their bugs or not tell the testers about new code they wrote in hopes that fewer bugs will be found. You can't win.

Besides, what is lots of code? If a programmer writes some lengthy and redundant code while another one solves the same problem with a clean subroutine, who's the winner?

Personally, I have achieved good results by giving the developers full responsibility for an application or a given feature and letting them set the milestones for their work, under my loose supervision. When the feature was released, I gave them full credit with the users. Hubris was a good incentive. It worked. I am not sure it could work everywhere. But depending on the environment it could be better than a policy of strictly checking how many lines of code were written.

 _  _ _  _  
(_|| | |(_|><
 _|