In my experience, the most productive rockstar programmers in an organisation are almost always people who are truly passionate about what they do. So the trick is to find people for whom the "work itself is the reward", not some "external" stimulus such as better pay.
As for how pay rises should be done - I'm not sure. I've always essentially just been a grunt programmer and have never been in a position to have a say in this. But from my point of view, I've actually always liked working for companies where the hierarchies and pay scales were relatively flat.
As Spolsky says, programming output is notoriously difficult to measure. Some people are good social catalysts in a group, others are better straight up quiet-achiever programmers, etc. A given manager might not be able to see the synergy for what it is, and none of the traditional metrics can really quantify anything useful here.
To be honest, I think the best kind of performance and salary reviews are relatively informal ones. eg. If someone is an obvious problem employee, or obvious outstanding employee, of course that should be pointed out. But the more fine grained it gets the more it just causes needless stress. Also, I find that programmers are mostly happy so long as they are getting average or above pay for their given specialty. So as long as you're not outright screwing them (by, for example, not giving a raise that covers inflation + a token bit extra, or outright underpaying for that specialty in your market), a quick and informal review and inflation index raise every year should be all you need.