The Downside of Going Quickly

Perhaps it's because I'm a capitalist at heart; perhaps it's because I'm from a family of economists (thanks for the condolences); but Dan Pink's TED talk about how pay-for-performance reduces productivity has been haunting me a bit.  Surely there must be some way to exploit the profit motive in creative endeavors?

The other way of looking at it, which seems glaringly apparent in a lot of our projects, is that there's no downside to going slowly.  Of course, no one's twiddling their thumbs for hours each day, delaying real work.  But if you've got a choice between one unit test and twenty, which do you choose?  I'd guess most programmers would choose to write twenty, so they can feel confident that the code they release is error-free.  After all, while there's no downside to going slowly, there's typically a huge downside to being responsible for a bug that makes it to production.  Not only is there stress involved in fixing the bug, but chances are a much wider audience has discovered the issue, and no one wants the pressure of being responsible for a public problem.

So if there's no downside to going slowly and a fairly big downside to missing bugs, of course projects will take a long time.  To counter-act that tendency, you've got to offer some upside to finishing a project quickly.

But doesn't that bring us back to pay-for-performance?  Yes, in a way.  But I think the key difference is task productivity and project productivity.  If you imagine being given a complicated math problem, and are told, "You'll get $1,000 if you solve this in a minute," would the money help?  Probably not.  Financial incentives don't help you think faster, which is essentially what you'd have to do.  If anything, as the TED talk suggests, the money would add pressure and therefore distraction to your efforts, and lead you to actually go more slowly.

But now consider a different approach: you're given 100 complicated math problems, and told that you'll get $1,000 if you solve them within a week.  To me, that's an entirely different system.  Now, you're not being rewarded to think faster, you're being rewarded to figure out a system to tackle the problems as efficiently as possible.  Maybe that means scanning all 100 problems so that some unconscious part of your brain can be working on them while you sleep.  Maybe it means categorizing them so that you can remain in the same mindset while you tackle a group of them.  Whatever your strategy, you're being rewarded for figuring out how to get the best performance out of yourself.  And surely that must be beneficial and worthy of considering for the software development process.