Sins of Commissions
Reading Joel Spolsky’s latest article, Sins of Commissions, reminded me about a topic that I feel very strongly about, namely incentives for software developers based on some kind of software quality or metric. I don’t know about you my dear reader, but I think this is just nuts!
Although Joel’s article talks about sales, incentives are also being applied in the IT industry. I personally know several employers where these kind of ‘commissions’ are being given to software developers. These incentives are mostly based on metrics like code coverage, cyclomatic complexity or some other result coming from a static analysis tool. Applying such a rewarding system to software development is doomed to fail.
From the article:
Inevitably, people will figure out how to get the number you want at the expense of what you are not measuring, including things you can’t measure, such as morale and customer goodwill.
…
His point is that incentive plans based on measuring performance always backfire. Not sometimes. Always. What you measure is inevitably a proxy for the outcome you want, and even though you may think that all you have to do is tweak the incentives to boost sales, you can’t. It’s not going to work. Because people have brains and are endlessly creative when it comes to improving their personal well-being at everyone else’s expense.
This really hits it home. If someone gets paid based on e.g. code coverage, then he or she will find a way to write a single unit test that proves 350% code coverage to pay the mortgage. This totally defeats the purpose of quality metrics, betraying the rest of the team as well. Don’t say this won’t happen, because it most definitely will. You never ever achieve code quality this way.
Another sick form of incentives is rewarding people who have been in a death march for months, delivering yet-another-piece-of-unmaintainable-crap on a randomly picked date. If a team gets 3 months to deliver a software system that actually should take 6 months to build and gets rewarded for it, then the result will most definitely not be pretty. It’s always going to be at the expense of something else, code quality itself in this case.
Delivering quality code/software has nothing to do with incentives, but everything with being a professional software craftsman who wants to do the best he can regardless of his salary.
Until, next time.
What you measure is inevitably a proxy for the outcome you want
But what if you could actually measure the outcome that you want? Not code coverage metrics, but customer satisfaction or decreased calls to tech support.
Or, hell, what about rewarding people for helping to build a culture of quality within your organization by rewarding those who are able to help others learn techniques for developing better software (okay, I guess this is a proxy too – but I’d rather work for an organization that gives some thought to which people to reward based on their actions rather than blindly rewarding whoever has the best #s from some automated code analysis tool).
I know people like to obsess on the easy to measure code metrics but I feel like that’s just taking the easy way out . I’m sure it’s harder to come up with measurements that are more closely tied to the behaviors we actually want to get. But, it strikes me that if we can be agile and iterative with developing the software, then the companies we work for should be able to be agile and iterative with determining the best way to reward people for delivering the results we want. And if people eventually find ways to game the system, maybe that’s all the more reason to keep changing the way those rewards are determined. Just a thought…