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
There was an article on slashdot about this a while back. http://slashdot.org/article.pl?sid=02/03/14/1939246[^] It basically came to the conclusion that any kind of measure will probably be wrong. E.g. If you give 2 people the same problem, is the guy who produces a 100 line solution a better programmer than the one than can solve it in 25 lines? Or if a programmer sits down, and notices a bit of code is reproduced everywhere, and so turns it into a function, thus reducing the number of lines in the code. This is good practice, but a negative number of lines have been produced -- Help me! I'm turning into a grapefruit!
-
Andy Cowenhoven wrote: Any ideas on this?
If (Developer.TaskCompletedDate <= Task.DueDate && Task.Code.DoesWhatItIsSupposedToDo == true) then Developer.Productive = true;Seriously though LOC is rubbish and what on earth is "function points" ? If your company has to implement methods like this then I think it has problems. There must be someone in "charge" of the developers who can give a judgement call on their productivity. And really it comes down to did they do the job well and on time or not. If there is no one to judge that then who is managing them?Paul Watson
Bluegrass
Cape Town, South AfricaI find I get much LESS done when I'm always updating my progress/status for managers... and then eventually I get a completely bad attitude about the managers and the company. If a manager is constantly trying to figure out how productive you are, the manager is implying that you're NOT productive enough, and they need to find ways of getting more out of you... Many, many problems in both the public and private sector could be solved by simply chopping out a sizable chunk of the administration/management layer and let the employees do what they were hired to do! "Our contest is not only whether we ourselves shall be free, but whether there shall be left to mankind an asylum on earth for civil and religious liberty." --Samuel Adams
-
I find I get much LESS done when I'm always updating my progress/status for managers... and then eventually I get a completely bad attitude about the managers and the company. If a manager is constantly trying to figure out how productive you are, the manager is implying that you're NOT productive enough, and they need to find ways of getting more out of you... Many, many problems in both the public and private sector could be solved by simply chopping out a sizable chunk of the administration/management layer and let the employees do what they were hired to do! "Our contest is not only whether we ourselves shall be free, but whether there shall be left to mankind an asylum on earth for civil and religious liberty." --Samuel Adams
Chris Hambleton wrote: Many, many problems in both the public and private sector could be solved by simply chopping out a sizable chunk of the administration/management layer and let the employees do what they were hired to do! Well from that I can tell no matter what I say it will not change your mindset. Suffice to say more respect is due (both ways) and this manager/employee feud is silly. There are as many bad employees as their are bad managers, we are all human. Chris Hambleton wrote: I find I get much LESS done when I'm always updating my progress/status for managers I agree, that is a poor method of feedback and tracking. It is your managers job to track these kind of items without interfering with your productivity. Obviously though there needs to be an initial commitment by the employee as to when an assigned task will be complete. Chris Hambleton wrote: If a manager is constantly trying to figure out how productive you are, the manager is implying that you're NOT productive enough, and they need to find ways of getting more out of you... Remember managers have bosses too and just like you it is not easy to tell a higher power to sod off, even saying it nicely and logically sometimes does not help. All in all more respect please. "Do unto others as blah blah" you get my meaning.
Paul Watson
Bluegrass
Cape Town, South Africa -
Paul Watson wrote: If your company has to implement methods like this then I think it has problems. I smell a beancounter with too little to do... Every company I ever worked for or with that put an accountant in charge is out of business - there's a pattern here:-) Old malted hops and yeasts never die, they just slowly stupify...
Roger Wright wrote: there's a pattern here You mean "it all adds up" :rolleyes: You can tell how close to hometime on a Friday it is for me by the quality of my jokes... :-D We have a salesman and a finance boff in charge here... luckily when it comes to tech they listen to me, and I listen to them when it comes to finance :) But an accountant in CHARGE would be bad.
Paul Watson
Bluegrass
Cape Town, South Africa -
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
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...
-
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