In the conversation at slashdot about Why Crunch Mode Doesn’t Work, there is discussion of the root causes of Crunch Mode: management incompetence; estimating incompetence; the nature of games; feeping creaturitis (OK, they really said “feature creep”); the marketplace (and attendant hard deadlines); previous success using crunch mode; late product specs; inadequate or missing product specs; failure to update schedules; difficulty of estimation; a combination of hard deadline and hard feature set; lack of management training; developer desire to be ‘leet’; and inexperienced staff.
I’ve experienced most of these, and while I agree that all of these problems can contribute to the inappropriate or extended use of extra hours, I disagree that any of these are the root cause of most crunches.
I think the ultimate top-down driver of long-term crunch is a combination of testosterone and fear.
Testosterone’s contribution is obvious and is noted in some of the slashdot comments: programmers want to be ‘leet’. I think that particular explanation barely scratches the surface, because it addresses the problem only at the bottom of the pyramid. But I don’t believe long-term crunch mode can be successfully driven from the bottom up — it has to come from the top. Partly that’s because anyone who drives themselves too hard for too long begins to realize how wasted they are and how little work they’re getting done. Managers want to be seen as players, as people who successfully motivate their teams, as people who took on difficult (or impossible!) jobs and got them done. In short, they want to prove their manhood (mind you, that’s just a pat diagnosis made without first obtaining [a] full medical history). John Perry Barlow called testosterone “the original stupid drug” when speaking to a CGDC audience, and I think in this case he’s absolutely right.
This theory requires some sort of precipitating event: a failure to make milestones; proceeding at a rate considered (by someone) unacceptably slow; having a product that isn’t fun early on; or something that raises the possibility that this project will be less than a stellar event. I think that we can find something of that nature on pretty much every project ever done 
.
Testosterone is bad enough, but when you mix it with fear you get real trouble. For all the reasons listed as root causes of crunch mode, and a whole host of others, making a project run on schedule without major problems is hard. It’s natural to expect that there will be difficulties, and since hard ship dates are a way of life (especially in games), problems probably involve the schedule. When anyone (but especially an inexperienced manager) finds out there are problems (especially serious ones) in their work, there’s going to be concern, maybe even fear. Add to that the testosterone-laced environment of most game development companies (Passion! Long Hours! Constant Competition!) and you’ve got a rich hormonal mixture that’s well designed to create fear. Fear of failure. Fear of appearing weak or stupid. Fear for your job. Fear of being out of control. Fear of being found wanting. Fear, in short, of being insufficiently manly.
Fear and anxiety are known to reduce comprehension and learning ability. W. Edwards Deming made “drive out fear” one of his 14 management changes America needed to make in order to compete with Japan. Fear is a valuable physiological reaction in some situations, but fear make it difficult to think, and thinking is generally superior to fighting in most corporate settings.
As a testosterone driven response to fear, crunch mode makes sense. It avoids any appearance of failure. If there is a failure, it’s been made clear that everything possible was done to succeed.
And that is the most insidious thing about crunch mode: as a response to scheduling problems, it provides exactly the opposite of what you need. When you have a schedule issue you need to tighten up: make sure you’re doing only the necessary work; make sure you’re doing work right the first time; and make sure you’re getting the most out of your people and equipment. Long term crunch mode tightens nothing but sphincters: productivity drops immediately upon starting longer hours; mistakes increase (especially if the hours are long enough to cause sleep deprivation); and very quickly (depending upon the number of extra hours worked) total weekly output drops.
The use of crunch mode as a long-term management technique is a cultural problem, not a technical one. Improving schedule estimation won’t fix it. Reducing feature creep won’t fix it. Software development is not an exact science. There will always be problems that arise during development. Many of them will have to do with the schedule or other non-negotiable aspects of the project. As long as those problems engender fear in workers and managers, it will be difficult to get those workers and managers to make good decisions.
Managers need to feel secure enough in their manhood, er, jobs to do what is most likely to get the job done rather than what makes them look good. Managers higher up must make sure that the organization rewards success not the appearance of working hard. Organizations must discourage ineffective techniques used by managers. EA wouldn’t allow line managers to provide workers with 90MHz Pentium II development systems — why should they allow the use of long periods of extended hours when it’s well known to reduce total output?