This blog post is because I can't fit my comment in 140 characters and it's a rebuttal to StackOverflow podcast #77 - specifically in regard to why productive programmers can't be paid 10 times as much as unproductive ones.
The argument goes that you cannot effectively measure programmer productivity because lines of code doesn't equal productivity, number of bugs per lines of code doesn't measure productivity because what if you only write 1 line of code and there are no bugs in it etc etc, I've heard all the arguments why this cannot be done and I'm still in disbelief that people as influential as Joel Spolsky and Jeff Attwood couldn't put their intelligence together and come up with some metric that justly rewards superstar programmers the same way that superstar sales people are rewarded.
Everything about a successful business is based on metrics, and it's these metrics with programmers that seem to be impossible not to be gamed. Who cares about whether or not the system is gamed? As a business person, I don't give two hoots about whether or not you're gaming the system. I couldn't care less. What I do care about is how you're affecting my bottom line. That comes down to one of two questions - "Are you making me money?" or "Are you saving me money?". And specifically in relation to those questions - "How much?". Pay not only your rock star programmers, but all your programmers based on that!
When it comes to business, every outgoing should have the question attached "How does this benefit my bottom line?". Forget whether or not your programmer is a rock star computer scientist that spends months writing a flawless project that does next to nothing but is completely bug free vs. the idiot you hired for peanuts that did it all in 2 days but it fell flat on its face as soon as it was released to the wild because it only worked in perfect conditions. Forget measuring lines of code vs. number of bugs per line. Ask the same question about the programmer's salary as you would for any other member of staff: "How have you helped my bottom line?".
If the code they wrote has worked well enough to save the company money, reward the programmer for that. If the code they wrote earned your company millions of dollars, reward them for that. If the code they wrote that has a net cost your company, pay them their minimum salary or hourly rate, fine them or get rid of them.
Of course, this seems very black and white, and there is certainly some grey area, just like any other metric - what if your rock star programmer has cost your company money in the short term because the software needed to be completely restructured, (s)he has put up a convincing argument why it should be restructured, and their argument has been verified as technically sound by an unbiased third party - well, they don't necessarily earn their commission or bonus this month and only get their salary. However, next month the company reaps huge rewards for their work and the bottom line is affected positively in a huge way. When the code is released and the bottom line earnings are calculated, pay them a bonus for their efforts.
Now, I'd like to add a disclaimer that this doesn't necessarily guarantee that the best and most efficient code (from a technical standpoint) will be produced, but it does mean that what needs to get done will get done in the most efficient manner from a time perspective - everyone wants their bonus, poor quality code that has bugs that cause customers to stop using the software affects the bottom line negatively and as such no bonus. Bugs that nobody cares about would take lesser priority over those that people care about. In the real world, this is how rock star programmers (and all programmers in fact) can effectively (and in line with business objectives) be paid on the same scale as sales people.
When your team starts looking at the long term benefits of writing code that saves/makes the company money, they will start to see that it's in their best interest to write the best code, from a maintenance standpoint, from a performance standpoint and from a usability standpoint, and they will be enticed to do this by significant financial reward.