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.

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.)

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. :)

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.