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
How about looking at Bugs Reported and Bugs Fixed? Jon Sagara Damnit Jim!
-
LOC is irrelevant, except you can probably say that the developer that generates less LOC to solve a problem is probably the better. As to productivity, you can only measure how fast (and maintainable!) the code was delivered. Someone delivering one gazillion lines of completely unmaintainable code in ten days to solve a particular problem could with the general "LOC productive" definition be very "productive", even that anyone would hate to take over after that person. On the other hand a good developer, generating maybe 1KLOC in 14 days (less code and longer time) for solving the same problem would by that definition be less productive, even that his/hers code could be from good design, maintainable and understandable, and no one would ever hesitate to use or maintaining it. From the "function points" document I only read "The size is measured from a functional, or user, point of view" and stopped. I usually create code that no end user ever see, but much of what they do see is based on my code. If my code don't work, they will see it (and be unhappy). If my code works, neither users nor other developers will ever think twice about it; it just "is there" and works as expected. If you relly have to stack these people up against eachother, create a real problem and put them to the test using the tools of their choice. The ones that solves it fast, with a good design while keeping the code maintainable is the best developers. For the factors used to measure "good design", "maintainable" and "time used", it's all up to you in what areas you want to screw your developers. Personally I measure productivity as a combination of design, maintainability, language used (i.e. anything written in VB is no longer supported in 2-5 years, but written in e.g. C++ we can use it 20 years from now), reusability, reuse of existing libraries and functionality vs. time. I believe you just can't measure this unless you know it yourself...
Mike Nordell wrote: From the "function points" document I only read "The size is measured from a functional, or user, point of view" and stopped. I usually create code that no end user ever see, but much of what they do see is based on my code. Actually, the term "user" does not always refer to the end-user. If you write a library, a programmer who uses your library is a user, isn't he? Every piece of software has a user. Otherwise it is - well unusable :) :beer:
-
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
This is a terrible idea. Measuring only one metric takes the whole process of software engineering out of context. Developer A might code 80 LOC/Hour but have 100 defects/KLOC. Developer B might code 50 LOC/Hour but have 2 defects/KLOC. Who's more productive?
-
LOC is irrelevant, except you can probably say that the developer that generates less LOC to solve a problem is probably the better. As to productivity, you can only measure how fast (and maintainable!) the code was delivered. Someone delivering one gazillion lines of completely unmaintainable code in ten days to solve a particular problem could with the general "LOC productive" definition be very "productive", even that anyone would hate to take over after that person. On the other hand a good developer, generating maybe 1KLOC in 14 days (less code and longer time) for solving the same problem would by that definition be less productive, even that his/hers code could be from good design, maintainable and understandable, and no one would ever hesitate to use or maintaining it. From the "function points" document I only read "The size is measured from a functional, or user, point of view" and stopped. I usually create code that no end user ever see, but much of what they do see is based on my code. If my code don't work, they will see it (and be unhappy). If my code works, neither users nor other developers will ever think twice about it; it just "is there" and works as expected. If you relly have to stack these people up against eachother, create a real problem and put them to the test using the tools of their choice. The ones that solves it fast, with a good design while keeping the code maintainable is the best developers. For the factors used to measure "good design", "maintainable" and "time used", it's all up to you in what areas you want to screw your developers. Personally I measure productivity as a combination of design, maintainability, language used (i.e. anything written in VB is no longer supported in 2-5 years, but written in e.g. C++ we can use it 20 years from now), reusability, reuse of existing libraries and functionality vs. time. I believe you just can't measure this unless you know it yourself...
Mike Nordell wrote: I believe you just can't measure this unless you know it yourself... Yes, exactly - I think you have nailed the problem here. I know what is going on, and report it to managers in a non-technical manner that skirts issues that are not understood by non-programmers. I think they sense this and want an "objective" measurement. In some ways it would be nice to be able to measure a programmer the way you measure a salesman - with an unambiguous metric like dollar amount. People have tried, but that measure does not seem to exist yet. Andy Cowenhoven
-
How about looking at Bugs Reported and Bugs Fixed? Jon Sagara Damnit Jim!
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
-
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
Andy Cowenhoven wrote: 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! IMHO, more bug reports/fixes means that people are being more accountable for the software they write. In a perfect world, you're right, the bugs never should have been there in the first place, but unfortunately I have yet to meet a developer who can code like that. :) When people write code, it's a given that they will introduce bugs. If a person consistenly writes bad software, you will be able to tell because his/her component never works correctly, and you can just sack him/her, and this metric really won't matter. However, for the people who actually do good work, this can help you measure in some way how productive they are. You should read the first few chapters of Debugging Applications by John Robbins. He gives a good overview of successful and unsuccessful dev teams that he has been a part of. Debugging Applications[^] Jon Sagara Damnit Jim!
-
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
Good programmers don't relie on the amount of code they produce. Take:
if (a == b) { c = 10; } else { c = 12; } or c = a == b ? 10 : 12;Does that make me more productive for using less line of code :~ Developing with C++ is like programming by the seat of your pants -
Mike Nordell wrote: I believe you just can't measure this unless you know it yourself... Yes, exactly - I think you have nailed the problem here. I know what is going on, and report it to managers in a non-technical manner that skirts issues that are not understood by non-programmers. I think they sense this and want an "objective" measurement. In some ways it would be nice to be able to measure a programmer the way you measure a salesman - with an unambiguous metric like dollar amount. People have tried, but that measure does not seem to exist yet. Andy Cowenhoven
Andy Cowenhoven wrote: I know what is going on, and report it to managers in a non-technical manner that skirts issues that are not understood by non-programmers. I think they sense this and want an "objective" measurement. Currently impossible. Software development isn't "construction". It's always a combination of analysis, design and construction. Development is still, even that it has many areas of "engineering", still an art (since we're constandly creating something new). How do you measure "art" in an objective way? If they want to measure "raw code productivity", perhaps getting a zoo of "code monkeys" and give them instructions so exact that it might have been the code itself, and then see how fast they manage to implement it? :-) In some ways it would be nice to be able to measure a programmer the way you measure a salesman - with an unambiguous metric like dollar amount. People have tried, but that measure does not seem to exist yet. So, do you really want to measure the "salesman" part of the developer, or do you want to measure the "manager" in the developer, the architect, the designer, the "general problem solver", the artist, the education s/he has, the knowledge, the ability to build sustainable and "upgradable" buildings, the ... A software developer often have so many roles inherent with his/hers job that there simply isn't a job more complex that I'm aware of. To be "good" you have to master so many disciplines that you could be compared to a 9:th dan Sensei, in at least five martial arts simultaneously! The only way you can measure that is by competition (and peer judgement). Anyone outside of this field simply don't know what to look for, much less judge it. I told you it would be bad parallels. :-)
-
Mike Nordell wrote: From the "function points" document I only read "The size is measured from a functional, or user, point of view" and stopped. I usually create code that no end user ever see, but much of what they do see is based on my code. Actually, the term "user" does not always refer to the end-user. If you write a library, a programmer who uses your library is a user, isn't he? Every piece of software has a user. Otherwise it is - well unusable :) :beer:
Nemanja Trifunovic wrote: Actually, the term "user" does not always refer to the end-user You are indeed right. But if I design a function that (without sacrifising speed, ease of use, flexibility, space and so on) does the work of three other functions, I am by that very definition less productive than the one creating three different functions. Every piece of software has a user. Otherwise it is - well unusable Why do we always have to remind Micros~1 about Bob?! :-D
-
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