Measuring Programmer Productivity
-
I'm supposed to implement a system to do this for a team of 10 - what a pain! The stats I know of are LOC (lines of code) and function points. I really question the value of LOC. And to be honest, I don't really understand function points - seems pretty complex. Any ideas on this? Andy Cowenhoven
Andy, see this link[^] re: function points. /ravi Let's put "civil" back in "civilization" http://www.ravib.com ravib@ravib.com
-
I'm supposed to implement a system to do this for a team of 10 - what a pain! The stats I know of are LOC (lines of code) and function points. I really question the value of LOC. And to be honest, I don't really understand function points - seems pretty complex. Any ideas on this? Andy Cowenhoven
There is no perfect measurement, but perhaps you can get a "fair" judgement by creating some type of index rating. Which takes into account each input(ie. LOC, time spent, task difficulty, time alotted/spent, bugs reported, etc.) then prioritize each as well, (ie. if bugs reported is important that ranks a five whereas LOC maybe only 2) Mix it all up in a hat and get a number. Mgt who wants metrics, will probably love this type of crap too. You can then make lovely graphs and cause competition amongst your staff taking focus away from quality coding, etc...... Obviously still imperfect especially since time alotted and task difficulty are guesses anyway. BW {insert witty/thought-provoking saying here}
-
I'm supposed to implement a system to do this for a team of 10 - what a pain! The stats I know of are LOC (lines of code) and function points. I really question the value of LOC. And to be honest, I don't really understand function points - seems pretty complex. Any ideas on this? Andy Cowenhoven
Ask yourself this: How would you measure [building] architecture productivity? NOW (Number of Walls)? NOF (Number of Floors)? NOO (Number of Outlets)? At my most recent job, I spent about 400 hours working on code that ended up being less than 1000 lines of code and most of that was a parser--the actual core engine was less than 100 lines of code. However, it not only sped up the operation in question by factor of 50,000, it added a huge amount of flexibity for the operations people and it saved the company over half a million dollars. It's slick as hell and among my proudest achievements.
-
Ask yourself this: How would you measure [building] architecture productivity? NOW (Number of Walls)? NOF (Number of Floors)? NOO (Number of Outlets)? At my most recent job, I spent about 400 hours working on code that ended up being less than 1000 lines of code and most of that was a parser--the actual core engine was less than 100 lines of code. However, it not only sped up the operation in question by factor of 50,000, it added a huge amount of flexibity for the operations people and it saved the company over half a million dollars. It's slick as hell and among my proudest achievements.
Joe Woodbury wrote: saved the company over half a million dollars There's a good metric. Money saved! Joe Woodbury wrote: It's slick as hell and among my proudest achievements. That's great. That's really what it's all about, isn't it? Andy Cowenhoven
-
Jon Sagara wrote: How about looking at Bugs Reported and Bugs Fixed? Not bad, especially for a team in maintenance mode. But would it be better to have more or less of this stat? Less means, presumably, that the original code was better. More means you have busier people fixing code which should have been right in the first place! Andy Cowenhoven