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.
January 12, 2010 at 10:43 am
every time i’ve had to pull an all nighter, i’ve ended up spending more time later undoing the damage. not to mention that everything took me twice as long when it was three in the morning.
January 12, 2010 at 1:11 pm
Oh man, I really had a “scales fell from eyes” moment reading this and the linked essay. Thanks for the nudge Rafe.
http://www.librarian.net/stax/3126/on-heroism/
January 12, 2010 at 6:33 pm
As a software QA engineer, I agree completely.
A QA engineer interview question you sometimes hear is, “Tell me about a time when you had to put your foot down for quality.”
My response is: if things get to the point where I have to ‘take a stand for quality’, then the process is seriously broken, and furthermore, I have not done my job of assessing risk throughout the process. That seems similar to me to your ‘all-nighter.’
January 13, 2010 at 8:59 pm
Yes.
Good planning and requirements don’t require (constant) heroics. Looking back on the times in my career when all-nighters, or their equally abhorrent sibling “working late” were required, they were overwhelming products of the process. In some ways, I could have made them better, but inherently, the projects themselves had structural issues.
In a management role, I understand there are cases of poor time-management. But looking at my team, if I’m seeing someone pull an all-nighter, my first question is, “What part of my job did I screw up?”