|
Programmer Productivity Question
It's often suggested that a great programmer will be n times more productive than a good programmer, who is in turn m times more productive than a fair one. My question is, what's the unit of measure of programmer productivity? Lines of code? Modules? Is "programmer productivity" just a subjective observation on the part of the people making these assertions?
Adam N
Wednesday, February 4, 2004
I'd say the number of functionnality / bug fixes of similar importance that are designed + implemented + tested in a fixed number of days.
This is very far from counting lines of code.
Renaud Martinon
Wednesday, February 4, 2004
No one has come up with a good minute by minute or even day by day comparison metric. And it certainly doesn't work when comparing languages - you just tell me about LOC as a metric and I'll point you to one of my COBOL programs...
Probably the best you can do is become familiar with the coding practices of the programmers and/or be very familiar with the language(s) in question and look at the programmer's ability to complete the task with as few bugs as possible. (and let's not forget documentation/comments and language niceties)... it's a complex thing.
Lou
Wednesday, February 4, 2004
Measure in Beans. A Bean is a six minute increment. How many Beans worth of development did you get done today?
But seriously - Productivity leads to success. Success is a happy manager. How happy is your manager with your work? This is brought to you by the code is used to promote business school of thought.
m
Wednesday, February 4, 2004
From what I gather, then, there is no real metric for programmer productivity. Thus, whenever we read about supposed superstar developers producing orders of magnitudes more than others, we are free to take this with a grain of salt.
Adam N
Wednesday, February 4, 2004
how much time spent to fix a bug!
A method to tell good from bad.
reguard
http://www.d2ksoft.com
redguard
Wednesday, February 4, 2004
A player who makes the team great is far greater than a player who is great.
But, I guess that's the manager's job isn't it?
Wayne
Wednesday, February 4, 2004
The number I've read is an average 26x (that's TIMES) difference between the top and bottom programmers, usually measured in function points over some unit of time. But these were military projects.
H. Lally Singh
Wednesday, February 4, 2004
Depends how time is spent reading this list, slashdot.org and the like.
Really, my productitivy ranges from high (burst of enthusiasm about a new task) to dismal (debugging the last 1% on a project that just won't go away). Probably that 26X factor that someone else noted.
Bathmophobic skier
Wednesday, February 4, 2004
The studies that measured programmer productivity were based on giving the same specification to a large group of programmers, and recording the amount of time they took, among other metrics such as defects and lines of code.
It was common to find differences of 10X between the time taken by the upper quintile and lowest quintile, sometimes even as high as 20X.
Unfortunately, there isn't any long-term similar study because of the expense; these things typically took place in a single day or a weekend.
But that kind of productivity difference can be imprecisely observed in the real world - look at some pieces of software produced by a small company. If you had a similar sized set of average or poor programmers and gave them 10X the amount of time, would they be able to produce it? Or could 10X the number of programmers produce it in the same time?
Doom for example, was written by only 3 or 4 programmers. A set of 30, or even 300 average programmers could not create it.
NoName
Wednesday, February 4, 2004
>> "The studies that measured programmer productivity were based on giving the same specification to a large group of programmers, and recording the amount of time they took, among other metrics such as defects and lines of code."
Seems pretty darn nebulous to me. Given a particular specification, I can pound an app out quickly - if that is my goal. It usually isn't, though. I can take more time and craft custom data structures and research best-fit algorithms if my goal is program response time, or maybe throughput. If my goal is to craft a maintainable application I can spend some more time implementing popular design patterns, and making certain that my object model is clear and intuitive. I can spend more time making sure the app is user friendly...
The point is, just because someone meets specs twenty times faster than someone else, doesn't mean that his code is any good.
Adam N
Wednesday, February 4, 2004
The other aspects that you mentioned were also examined, and generally the fastest programmers also scored highly on those other aspects - fewer lines of code, fewer defects, better modularity, etc.
Read Tom DeMarco's book "Why Does Software Cost So Much" which has a chapter with details of one such study.
NoName
Wednesday, February 4, 2004
Interesting, NoName. Thanks.
Adam N
Wednesday, February 4, 2004
Okay, so if these are all traits of super-developers (i.e. "fewer lines of code, fewer defects, better modularity, etc."), then I wonder if coders are speedier *because* they have these traits. Any thoughts?
Adam N
Wednesday, February 4, 2004
"A player who makes the team great is far greater than a player who is great."
Egalitarian tripe. I'm ok, you're ok? Most teams will never be great in this league, because their rosters are so poor. This isn't the NBA, where even the worst player is phenomenally talented. Most shouldn't even be employed in this field, and only are because there's currently broad delusion that you can manage your way to quality with magic processes and interchangeable bodies. Bunk.
veal
Wednesday, February 4, 2004
Adam N, you're on the right track. Speed comes in part from not having to agonize over design decisions, from getting close to the ballpark intuitively, and from also intuitively seeing your mistakes quickly.
It's a talent thing. Imagine how much more quickly Tiger Woods gets through the course than, for example, me, spending so much of my time in the rough, setting up for more strokes, putting right past the hole three times.
veal
Wednesday, February 4, 2004
This all started in Peopleware, Chapter 8.
You do have Peopleware right?
It's 10 to 1 from top to bottom. It's 2.6 to 1 from top to MEDIAN. And the top half on average is twice as productive as the bottom half.
Test was to complete a given task and done across samples of hundreds of programmers.
Top programmers coded the correct solution not just ten times faster, but with ten or more times fewer bugs. Presumably they did it in fewer lines of code as well, but that is not reported.
Clustering occurred - all the bottom developers were clustered at certain companies, all the top developers were clustered at OTHER companies (who wants to work with losers, right? Also, if your coworkers are idiots, it's statistically almost certain you are an idiot as well.)
* Top companies had quiet workspaces with private offices. Bottom cluster companies had noisy shops with frequent interruptions.
* Top and bottom developers showed no differences in salary. Hm.
* There was no correlation between productivity and experience for developers with any more than 6 months total life experience.
* There was no correlation between language used and productivity except for assembly. So, cobol, C, c++, basic, fortran - ALL ARE THE SAME. No language is more productive than any other. Except assembly which has close to zero productivity.
Dennis Atkins
Wednesday, February 4, 2004
unit of measure of programmer productivity = decibel.
Full name
Wednesday, February 4, 2004
THEN I'M THE BEST BA-A-A-A-A-A-BY!!! WOO HOO!!!!!
888
anon
Wednesday, February 4, 2004
To be precise: 1/decibel :-)
Full name
Wednesday, February 4, 2004
>* There was no correlation between language used and productivity except for assembly. So, cobol, C, c++, basic, fortran - ALL ARE THE SAME. No language is more productive than any other. Except assembly which has close to zero productivity.
The above is likely a reasonable assumption. However, that does not mean that when developing a business application (CRUD create, Read, Update, Date) application that all tools will give you the same productivity.
It is too bad that further studies could not be done on which IDE is better for given tasks.
It is not reasonable to try and write a 3d graphing program in VB when you got AutoCAD. It is also not possible to write a game in ms-access either.
So, for a given standard business application, a project done with ms-access will cost you $8,000, and the same project in VB will cost $25,000. So, some tools and IDE are FAR MORE productive when used correctly.
Sure, general coding stuff is little different from language to language these days, but the using the right tools for the right job can give you a 100 fold increase in productivity.
Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn
Albert D. Kallal
Wednesday, February 4, 2004
What Albert D. Kallal says seems to sound very plausible. Language of choice *has to* make a difference nowadays with so many options - each tailor made to a specific development task.
I'm also interested in this proposition:
"* There was no correlation between productivity and experience for developers with any more than 6 months total life experience."
Just doesn't seem to pass the common sense test. I can't imagine a newbie carpenter or a newbie silversmith comparing in any way with masters in their respective crafts. Similarly, I just can't buy that newbie developers compare to master developers. (Although, I suppose that master carpenters don't have to learn how to use a completely new hammer every couple of years when Microsoft decides to come out with Hammer.NET.)
Adam N
Wednesday, February 4, 2004
To be fair, the pro-programmer has value in the realm of big picture or architecture. To use the carpenter comparison, go frame a wall is great - but build me an armoire is another story.
m
Wednesday, February 4, 2004
Adam Neat, the observation comes from many sources and extends well back into the early days of software engineering.
Experienced and good programmers can easily assess the capability of colleagues without explicit metrics. It will be based on how elegant a solution is, how robust, how extendable and how bug-free.
It might include speed of development, but that does not seem that important to me. Speed of development, in my experience, usually correllates with sloppy work.
Me and the view out the window
Wednesday, February 4, 2004
>"* There was no correlation between productivity and experience for developers with any more than 6 months total life experience."
Hum, I can certainly agree that if you take a GOOD developer, then after about 6 months of intensive use of one new language/platform, then that developer is certainly going be up to speed for that platform. Certainly more gains continue to happen up to about 1.5 years into a new platform (that is just my experience, and perhaps some get up to speed faster then myself).
However, it is somewhat suprising that 6 months total experience did not seem to make any difference in productivity.
However, JUST looking at coding a problem, then the above does make more sense.
Take the design phase of the project, and I can assure you that the fellow with years of experience will in general be FAR better then that 6 months old hot shot coder. And, believe me, some of those 6 months coders can be so full of ......well...ok ......talent!
So, while again the coding rate may be similar, the ability to design and develop the project would not be the same at all.
I not really sure if I can, or even code faster now then my computing science days at University. Come to think of it...I might even have slowed down, and don’t do those all nighters in the computer lab anymore!
However, comparing my ability in the design phase/wise of the software?
Hum...no comparison, as I am now far better to come up with good designs.
Again, more details on how much that study represented the code phase Vs the design phase would shed much light here.
.
Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn
Albert D. Kallal
Wednesday, February 4, 2004
Well, I'm just repeating Peopleware's reported results. I do believe they are accurate though.
However, to give some ammo to both sides:
I imagine these experiments are for fairly small projects that are done in a few hours by one person. I doubt that all the reported effects scale and I am sure that the ones that do scale don't do so linearly. Thus, I would expect experience to help with large projects. You do need experience to architect right? I hope so, but maybe not.
I think the language results are probably true for the types of problems they had which must have been problems that could be easily implemented in any language.
Personally, I keep track of my own productivity metrics and although I would like to say otherwise, my productivity is the same as it ever was. So the finding regarding experience I suspect is probably true. We've all seen that old joke that is a set of programs to do hello world written by a novice, then an expert, then a guru... the guru writes thousands of lines in a mysterious language, accounting for all sorts of bizarre and unlikely errors.
Also true though is the comment that you could have 300 average programmers and they could not invent Doom from scratch before Doom existed. You need talent to do new stuff.
Ah, I could go on but I need to get away from the computer for a while.
Dennis Atkins
Thursday, February 5, 2004
Experience counts, but it's a far weaker factor than talent in writing high-quality software quickly. The talented programmer's programming experience accumulates faster and more richly than the untalented programmer. Class lines establish in the first year or two in the field, and thick lines they are.
That's true for many things, not just programming. Innate aptitude and ability are overwhelming. If I play soccer/futbol for thirty years, I'd still probably never reach the level Luis Figo played at as an 11-year-old. Perhaps some may prefer the example of Bobby Fisher and Chess.
veal
Thursday, February 5, 2004
veal, I like your analogy, and I buy it, but I'd characterize it a little differently. (I'll use baseball, though, since I'm in the US!)
From an early age, you can tell who can play baseball. Really, you have it or you don't. Same as in software development. But it'll still take an entire career for the 'haves' to hone their skills to be able to compete in the big leagues. Talent just gets you into the door - and you have to have it to get in - but once you get in, that's when the work begins. There's no substitute for hard work. Who said. "Genius is one percent inspiration and ninety-nine percent perspiration?" Of course I have no data... Just my intuition.
Adam N
Thursday, February 5, 2004
Genius is one percent inspiration, ninety-five percent perspiration, and twelve percent arithmetic skills.
anon
Thursday, February 5, 2004
Maybe productivity doesn't vary much by language when coding something new, but I'm sure as hell it makes a difference when it comes to maintaining programs written by somebody else. Perl is a notorious example - rapid for the programmer writing a new program, but nightmarish to understand and modify afterwards.
Of course part of the maintainability aspect is directly to the programmer -- it is possible to write a readable Perl program. However some languages encourage bad structure and practices more than others.
NoName
Thursday, February 5, 2004
You're of course right, Adam N, that even for a very talented player, getting into the big leagues requires hard work. But in our field we only have one league, and these days it seems almost anybody with reliable transportation can get in.
Nonetheless hard work does make a big difference at any talent level. But to put it visually, bad left to good right, the top bar shows how hard work can improve the mojo of the talented programmer, the bottom shows what it can do for the average programmer. That gap between is that thick line of class distinction I mentioned above.
*******************
******
Said another way, the top programmers I've known were usually more effective in their first year than the vast majority of seasoned 20-year veterans I've observed. By more effective, I not only mean raw programming speed, but also delivering easier to read code, more reliable software, better performing software, and better documentation, having better ability to describe what they've done, often even better account management and sales skills for those who were consultants (imagine that).
veal
Thursday, February 5, 2004
On the language question, I think some languages give a productivity advantage for certain applications, but not enough to compensate for talent differences. (And I do mean language, not IDE.)
I'd like to see a study that took the top performers in a C shop for example, and gave them 12 months of writing business applications in a language like C# or Java, comparing their performance before and after.
veal
Thursday, February 5, 2004
Programming is like sports, as others above have made the analogy. A gifted, hardworking rookie can be better than many 8-year veterans of the game, but when that rookie has put in 8 years he will almost certainly be better than he was as a rookie (if he's still in the sport).
Similarly, better tools and equipment can make an athlete perform better but won't make up for significant differences in talent. Lance Armstrong benefits from having a super-light high-tech bicycle, but he would still whoop any of us if we had his super-duper bike and he was riding a $100 bike from K-Mart instead.
T. Norman
Friday, February 6, 2004
> the top programmers I've known were usually more effective in their first year than the vast majority of seasoned 20-year veterans I've observed ... often even better account management and sales skills for those who were consultants.
veal, you wouldn't be a first year graduate working as a sales consultant, would you?
> I'd like to see a study that took the top performers in a C shop for example, and gave them 12 months of writing business applications in a language like C# or Java, comparing their performance before and after.
This confirms it. Language effects are boring and irrelevant in the sense of discussing superior development capability.
Me and the view out the window
Friday, February 6, 2004
I've had teams of programmers where one guy wrote more code than all the rest put together--even on teams of 20 programmers or more. And in every case, it was that one guy's code that actually worked the best, so he'd spend most of his time debugging the others' code.
Nathan Cheng
Wednesday, June 2, 2004
 Recent Topics
Fog Creek Home
| 
