Always remember the classic story about "where to put the X"...
Have you ever heard of Charlie Steinmetz? Legend has it that he was a prominent electrical engineer in the early twentieth century. Not long after his retirement, all of the engineers at General Electric had a problem. Although each was wise, they were unable to understand the complexity of the machinery. A call was made and Charlie Steinmetz came to the plant to offer his assistance.
Ol’ Charlie walked around the machine for a few minutes, just looking it over, not touching anything. After a few minutes, Charlie took out a piece of chalk, walked over and placed a large X on one particular part of the machine. When the other engineers disassembled the machine, they were amazed to find that it was exactly where the problem was. A few days later, the engineers received an invoice from Charlie for $10,000! This was a lot of money in those days, so they returned it to Charlie and ask that he itemize it. A few days later, they received an itemized bill which read:
Making one X mark – $1.00
Knowing where to place the X – $9999.00
Even if one tosses the idea that there are "rockstar programmers" who are 10x more productive than merely good ones, someone with the right experience and domain knowledge can be priceless. I have certainly found cases in which I could merely hear the symptoms of a very subtle bug and find it in 2 minutes, whereas a great programmer unfamiliar with the codebase, field, and my past experience might have taken a week to find it.
There's a really similar story about Picasso asked by a lady in a restaurant to draw a simple sketch on a napkin. He does and hands it to her saying, "That will be [X] thousand dollars". Shocked, she says: "But that only took you 30 seconds!" "Madam", says Picasso, "It took me thirty years."
There are so many variations of that story floating around that someone may have heard it, but not recognize any detail of the version you gave. http://answers.google.com/answers/threadview?id=183998 cites several other variations for comparison.
Never meaningfully demonstrated? Have you tried to verify the claim?
Go read Peopleware. You will find described very carefully set up coding comparisons that routinely found a factor of 10 productivity difference between different experienced programmers on the same task, and also a discussion of what organizational factors lead to those productivity differences.
I thought the Peopleware claim was that some teams are 10x more productive than other teams. I could easily buy this, because it's very easy to generate more internal communication work than it produces, i.e. be negatively productive.
I'm not sure I buy it for individuals, except in the limiting case of someone completely not knowing what they're doing and having no idea where to start.
I guess it's also possible with the economist's definition of productivity ($$$/hour), since so many projects turn out to be commercial flops. But by that definition, startups and research are some of the least productive sectors of the economy, not the most.
No, Peopleware's research was on the productivity of individuals at different organizations. To be precise what they did is arranged a series of "coding wars" where multiple organizations would each select 2 individuals and all would code up solutions to the same problem in the language of their choice. People were asked to keep a log of what they did, and describe various things about their environment.
They found an order of 10 productivity difference that showed up under any of a number of possible measures. The also found that the best predictor of a given person's productivity was the productivity of the other person from the same organization. They also identified a number of workplace environment issues that were strongly correlated with productivity.
This overall picture comes with many caveats. Individual productivity differences were still quite significant. They didn't have any way to tell correlation versus causation. (To what extent does a better environment make programmers better, versus correlate with being able to hire and retain them?) The coding assignments were fairly small. So don't read too much into the result.
But given the size of the difference, and that it is one of the few attempts to quantify these issues, it isn't a result to take lightly either.
Well, I just googled the peopleware citation and it seems the study backing this often repeated claim is from the 1960s and people have plenty of questions about its methodology.
I'll easily buy 2X or 3X productivity difference. I'm not buying these casually tossed off claims about 10X or 30X productivity differences without the supporting research discussed in detail front and center. Unacknowledged differences of that magnitude would imply a massive arbitrage opportunity that has persisted for many years. And that's just not realistic.
If you view computer programmers as mental ditch diggers, then the idea that one could be so much more productive than another seems crazy. But when you see it as a creative endeavor, it's completely rational that some could be orders of magnitude more productive, even infinitely so.
For example, when you have a hard problem (like a networked 3d game with physics) that is beyond the abilities of a developer A (he can't solve the problems at hand, no matter how much time given), but not developer B (a creative thinker who can solve the problems quickly), then I think you can literally say Dev B is infinitely better than dev A for those hard problems. Because it's going to take you infinitely many developers A's randomly poking at their keyboard to solve the problems. But dev B will solve them in a reason amount of time.
Now dev B isn't infinitely smarter, but for certain tasks, he's infinitely more productive. The point is the productivity differences are highly context dependent, and the greater the creative and cognitive load of the tasks, the the greater the measurable productivity differences between the highest and the average developers.
1) Knowledge is entirely linear. If there some tasks programmer A fails at and some tasks programmer B fails at, then all you have is an apples-to-oranges comparison (which is what a lot of the x10 chest-pounding comes down to).
2) Knowledge isn't shared in the group. My proudest moments have involved actually teaching my co-workers how to write a recursive descent parser, why ACID matters in databases or how to divide a multi-threaded application between worker and consumer threads. It might be true that if I'd just kept my knowledge to my self and laughed as they failed, I might have been a 10x or even a 100x programmer. But it was more pleasant and satisfying to be the guy who actually helped everyone.
Slight nitpick: Infinite developer As will not solve the problem unless you assume that each developer can solve a finite part of the problem. If Developer A simply can't solve the problem none of them will help.
I don't know what you found through Google, but it was a bad description of the research cited in Peopleware. For a start the research they discuss was done in the 1980s, not the 1960s, and the methodology of their study was quite carefully done.
Read http://javatroopers.com/Peopleware.html#Chapter_8 for a much better overview of what Peopleware actually says. Of more interest than the productivity differences measured is the discussion of what factors were part of those productivity differences. Once you've read that, you may find the result much more believable. (There is a lot of detail in the book that is left out of the summary, but that's in the nature of what summaries are.)
I've experienced a 10x difference firsthand - and not against bad coders, but against average ones (they were former game developers, so they're quite possibly above average vs. the rest of the software industry). And you can slice the productivity along a bunch of different axes - systems designed and built, loc (not a great metric), complexity, features, etc - and the metrics still hold up.
That said, this order of magnitude is pretty rare (and it was against the slowest of the programmers) - but if you have a few true superstars, you can expect at least a 4x difference against the average in a group.
As far as compensation goes, at my last internet startup there was approximately a 5x difference, once you factor in bonuses. In the games industry, it was more like 2.5x.
For the worst coders, we tended to fire them after a few weeks if they somehow made it past the interview process. So there was a well-correlated difference in compensation there - we either paid them a few weeks of salary or 0$ in the latter case. :)
Unacknowledged differences of that magnitude would imply a massive arbitrage opportunity that has persisted for many years.
Only if "programmer productivity" is a primary limiting factor and one can reliably distinguish relative productivity beforehand, both of which strike me as unlikely in most situations.
I think that part of the problem is unqualified programmers are part of the equation. The amount of "developers" out there who have no idea what they're doing is shocking. The dot-com implosion helped cut some of the excess weight, but there are still a lot of people working in software who have no excuse being there.
In one particular area of programming, competitive programming, productivity is easier to measure.
One might call Tomek Czaijka the Federer of algorithmic competitions. As of 1.5 yrs ago, he had made more than $130k off of TopCoder competitions [1]. Seeing as how he is still ranked 3rd, this figure might be outdated [2].
I can assure you the average TopCoder contestant who has competed over a comparable amount of time made way less than $130k/30 ~ $4300. Easily more than 30 times the productivity.
You can argue about how coding up toy programs compares to working on products. I suspect there is a strong correlation though.
As a point of reference, please consider Steve Newman, who co-wrote Writely which was subsequently acquired by Google and is today the word processor of Google Docs [3]. He must have made some money in the process and was also successful at topcoder.com [4].
That being said, I do knew similar people with astonishingly low "product" productivity.
This is often repeated, never meaningfully demonstrated. I doubt it is true if we are excluding unqualified programmers.