Relation between developer's quality and compensation is a hot topic. Lots of e-ink has been spilled over this issue but not much crystallized in the end. Unlike lawyers who have established a baseline price of their work, developer's pay fluctuates wildly and is not necessarily related to the quality of their work (in fact, more often it boils down to how good negotiator you are). Quite often you'll see developers (who recently started contracting) asking for help on how to price their work on a public forum. Clearly we need some kind metric to measure developer's productivity, but even more we need to understand the quality of the work, more than the quantity.

Martin Fowler's Cheaper Talent Hypothesis is a great read that covers many important points. The relevant piece that talks about quality says:

Faster cycle time leads to a better external product, but perhaps the greatest contribution a talented team can make is to produce software with greater internal quality. It strikes to me that the productivity difference between a talented programmer and an average programmer is probably less than the productivity difference between a good code-base and an average code-base. Since talented programmer tend to produce good code-bases, this implies that the productivity advantages compound over time due to internal quality too.

I'd say this is actually the most important aspect. Of what use is the ton of code if it doesn't work? In one of the previous companies I worked for, an informal study showed that every bug that ends up in developer's lap (confirmed bug that needs fixing) costs the company, on average, one thousand euros. The reason is not that developers' time is expensive, but that the problem needs to be processed by support personnel, repeated, described/documented and after the developer is done fixing, the issue needs to be confirmed as fixed.

Think about this. With a couple of bugs "generated" a cheaper but lower quality developers will nullify the salary difference. Or vice-versa: with each bug not created a more expensive but higher quality developer will cost you less.

Unfortunately not many (if any) companies look at the problem this way. Usually the only metric is how fast one can reach the "finished" product state. The time spent in fixing all the issues introduced by rushing the product out of the door never "counts". It's a shame.