Why Do Software Developers Tolerate ‘Crunch Time’?

Given the well known increased risk of burnout for an extended "crunch time," why do developers put up with it? 

For software developers, "crunch time" is a period prior to a major product milestone when team members are asked to put in extra effort to get a product finished and polished by a specific delivery date.  Practically, this can be a horrific period of 80+ hour weeks that goes on for months as the team scrambles to deal with bugs, last minute feature requests and modifications, and milestones that can't be missed. For game companies and large internet retailers in particular, the mantra of "Christmas never slips" means that crunch time occurs during the summer to release products by the fall so they are available for purchase between Thanksgiving and Christmas. Recently, the wives of Rockstar Games posted an open letter to the management of the company about the impact of the crunch time on their lives. The company was demanding 6-7 days a week with 12-16 hour days starting from March 2009. The impact on their lives included mental, physical and emotional strain on the employees and their families.  This letter echoed a similar one from December 2004 from the spouse of an Electronic Arts employee who highlighted the poor working conditions and management.  

Reading the discussions on Slashdot about Rockstar working conditions highlighted that this problem occurs not only in game companies but is found industry-wide. As a developer and a manager, I have worked on a number of projects at various startups that involved periods of "crunch" that lasted longer than I thought was realistic.  When I was a young engineer working on Amazon Auctions, doing the all-nighter was a badge of honor. Eventually I discovered most of the code you write during those AM hours is likely to be thrown away. After a few "crunch times," I learned to be a better self advocate, and was able to better set expectations of what combination of features, quality, and testing I could and could not deliver by a given date. When I made the transition from developer to manager, I was glad to have had the experience so that I could help advocate for my teams. Although I couldn't always get rid of the "crunch time," I at least worked to keep their durations as short as possible.

Repeating the question: why do developers put up with "crunch time?"  I believe the reason is as simple as "Progress."   "Progress" was the factor that was most important to the workers as was found by two researchers who analyzed the diary entries of 12,000 workers. As long as the workers believe they are making headway in delivering their product they are getting an intrinsic reward that motivates them to work more. If you have a team making progress on a delivery, the combined effort of the team will self-reinforce and encourage them all for their efforts.  On Amazon Auctions, I worked on implementing search for the system and would nap while another team member would deliver new catalog content. By the time I returned we would integrate our code which would result in a complete auction search results. The work was rewarding despite the fact that we worked through the weekends to complete the project. The progress was beautiful and easy to see.  One day the system had "mockups" for search results and the next day the results would be feeding from live data.  The intrinsic reward of making progress and working with the team to deliver helped combat the potential for burnout. Still, friends of my pregnant wife did go so far as to create a fake press-release that they were happy that auctions launched and that this would hopefully mean I would be less of an absentee husband.

It is unrealistic to deliver any project without going through some "crunch time." Although progress helps to motivate employees during those periods, ineffective project planning can lead to an egregious amount of time where progress alone will not be enough to sustain the employees' or their family's motivation. If excessive "crunch time" continues to occur, the employees, the company's most valuable resource, should work either to change the organization or they will be compelled to move to a more supportive company. The books Peopleware, and Slack: Getting Past Burnout, Busywork and Total Efficiency are great reminders on why we should work hard to take care of our teams.