It's easy to make unit tests pass. To defeat this kind of gaming, you'd need extensive code review of the unit tests. But that circles around to your point: when you look at code there's something that tells you whether it's good or bad. That algorithm can't be based on passing tests, because tests are code too and also need review.

If you had a team of completely selfless developers, you could probably have code-reviews and peer-reviews drive incentives. But as soon as the team suspects it's a zero-sum game and they're competing for a limited prize, they're going to stab each other in the backs, and your best developer will be the prime target. That'll make your best developer leave, and the next-best becomes the target, until all you're left with are lousy developers who are only good at office politics.

Dysfunction may arise when you are unable to measure all the relevant dimensions of the work being performed. People will often shift their effort to the dimensions that are being measured and ignore the remaining tasks, no matter how important they are. This results in less value being delivered compared to a scenario with no measurement based incentives.

The author mentions software development as an area that is specially prone to dysfunction.