Alex Payne’s post Don’t Be a Hero is important, everybody should read it. In it, he explains why hero programmers do enough damage from a process standpoint to more than offset the value that their heroic efforts provide. Here’s the crux:
Heroes are damaging to a team because they become a crutch. As soon as you have someone who’s always willing to work at all hours, the motivation from the rest of the team to produce reliable, trouble-free software drops. The hero is a human patch. Sure, you might sit around talking about how reliability is a priority, but in the back of your mind you know that the hero will be there to fix what doesn’t work.
I want to discuss one particular aspect of heroism — the all-nighter. I am against all-nighters for one simple reason. Any problem or deadline that justifies pulling an all-nighter also justifies taking short cuts. Short cuts that in the end will cause more all-nighters, or result in your product being made up of horrible code that nobody wants to work on, or that will fail at exactly the wrong time. If it’s important enough to pull an all-nighter, it’s important enough not to go through the usual quality assurance process. It’s important enough not to write the unit tests you might ordinarily write. It’s important enough not to talk through the design with the rest of the team.
I’ve been the person who pulled all nighters or nearly all nighters, and while they’re good if you’re in need of a rush, they’ve never resulted in the code I’ve been proudest of, so I’m against them. And when they’re requested or demanded, something is going really poorly.