Earlier quoted context omitted.
There's an old quote I read and I keep it with me. It was for CEOs and it says, "You get what you incentivize." The hardest part of managing a group of people is incentivizing exactly what you want, yet so many people don't spend an ounce of thought tuning that properly. There's other people who believe process will fix everything, yet don't bother tuning their process. Many companies have fallen because the CEOs inc…
Code should be reviewed, preferably by a different group of people who wrote the code, metrics are only useful for people to manage themselves. Upon review there should be immediate feedback to people who wrote it and if they continue to make the same errors, then you should eventually get rid of the person who wrote it. Making up stupid systems of control to "incentivize" people as a method of management is the stup…
Oh, you don't like bonuses then? Unsolicited, forced code review doesn't have much value that I've found, unless your team is fairly junior. Senior guys know what good code looks like, even in a crunch. If you hold forced, unsolicited code reviews with senior developers, you are really just throwing away money and aggravating people.
It's just another half thought out process. A better incentive, in my opinion is: if you release a complete codebase with 0 medium and above defects by X date, you get a free week off, or something of significant value. A free, company branded desk clock doesn't cut it. (that's happened to me before).
If a company is trying to save money by hiring the cheapest offshore developers they can, they are still really just throwing away money and aggravating people. lol. That is a perfect example of a poor incentive: cut costs without any regard to the resulting cuts in quality. Anyone can make a turd cheaply, but that's rarely what businesses really want.