It was hard to find the time to write this column because we're in crunch mode right now. We're putting in sixty-hour weeks and we probably won't stop until we hit zero bugs, which could be three months away. Every project I do, I think that this time we'll manage it so well we won't have to crunch, and almost every project I'm wrong. I have worked on a couple of game projects that required almost no overtime: Interplay's Beat The House and Deluxe Wheel Of Fortune Featuring Vanna White. As you can imagine, they weren't terribly ambitious projects. Everything else required either a little or a lot of crunch.

You start talking about crunch time with developers and it quickly becomes a holy war with guys saying, "We can't be competitive if we don't crunch" on one side and other guys saying, "Studies have shown that programmers are at their most effective when they only work n hours a day."

I think both camps are right. In Rapid Development, Steve McConnell cites a study that shows coders being at their most productive when they work fifty-hour weeks. After fifty, you start seeing diminishing returns, as people get tired, start making mistakes, take more breaks, eat their catered dinners, or whatever. If efficiency is our goal, then we should send everyone home once they've put in their ten-hour day.

My first few articles make me sound like a big fan of efficiency, when I talked about bang for buck. But there's something more important than efficiency and that's return on investment. Example: McDonald's revolutionized fast food by making its burgers ahead of time. If it turned out nobody wanted the burgers, they got thrown away. Efficient? No. High return on investment? Yes.

Similarly, although we're not at our peak efficiency when we're working a sixty-hour week, we are getting more stuff done. And that more stuff may mean the difference between making Christmas (or a movie release date) or shipping late. It may get you those intangibles that make your game cross the line from three to four stars. It may get you a high return on investment.

Still, I do think a crunch is something we should try to avoid. Steve McConnell has a good rule of thumb: don't schedule for overtime. If you schedule people out as if they're only going to work forty-hour weeks, when things go wrong you can use overtime to catch up.

It's important to differentiate crunch from death march. With crunch, you achieve your goals: you ship, or you catch up to where you're supposed to be, and you stop crunching. With a death march it never ends; you get to your ship date and it gets pushed out. You get to another ship date and it gets pushed out again. The overtime never stops, because you're always really close to your supposed destination. The death march is the result of piss poor management. A crunch is a tool wielded by not-quite-so-horrible managers to catch up. If you crunch, you end up shipping a product you can (hopefully) be proud of; if you death-march, you end up quitting, or being fired, or seeing your project get cancelled, or seeing your company go under.

How do you tell a crunch from a death march while you're in it? It's hard. Here are some guidelines.

Here's how we do crunch on the Spider-Man team:

Everybody Crunches

It's all-for-one, one-for-all (whether we like it or not.) Although we make exceptions for reasonable circumstances, when we crunch, we all crunch. Usually at a meeting of the leads we'll decide that yes, we need to crunch. Greg John will draft an e-mail explaining the situation to the team, give the leads a chance to look at it, and send it out.

Some question the wisdom of this mandatory "everybody crunches" policy. "I got my stuff done," somebody might say. "I'm on top of things. Why do I have to stay late?" There are a few reasons I like it:

Once the project gets very near the end—the last few weeks—and there really is nothing for people to do, the "everybody crunches" system stops making sense. Then it really is better to send people home, and let the swat teams and burn squads ship the thing undistracted.

Crunch is about 60 hours a week

Although the details vary, crunch is usually around 10 hours a day on weekdays, 8 hours on Saturday. We adjusted the hours some to accommodate the desires of the team—although there are core hours when everyone has to be in (11 to 7 on long days, 11 to 5 on short days) there is some flexibility.

Crunch has clear goals

We have clear goals, whether it's "these things need to be done for an awesome E3 demo" or "these things need to be done before these levels will be considered alpha" or "we're fixing as many priority zero to three bugs as we can in the next ten weeks."

Catering a team of fifty or sixty is part of the challenge. At that number, it's futile to do individual orders, but better to order massive quantities of pizza, or BBQ, or fast food. Keeping some variety going is essential if you don't want to drive everyone mad.

We Rock Harder So You Don't Have To

One of the problems with crunch time is finding time to do your personal errands. Activision brought in a laundry service so laundry was one less thing we had to worry about.

Treyarch doesn't pay for lunch, but if somebody wants to work through lunch a producer or AP will get that person's food for them. (Even when we're not in crunch time.)

We spend maybe a quarter to a third of the project crunching, most of that coming in the last months. As I understand it, this is less crunching than most of the other developers I've talked to, and may be partly why we're pretty good at retaining employees on our team, although the main reason is probably the royalties.

Compensation

Although different employees are motivated by different things, I think a lot of us are motivated--at least to an extent--by cold, sweet, cash. Or maybe we just don't like feeling exploited, that our overtime is just going to make the CEO rich. Activision has a decent royalty policy, which helps us worker-bees feel like we've got a stake in the big picture. So although we're not paid overtime, we do come away feeling that we are compensated a little for our overtime by selling more units and making more money. Of course, that's on Spider-Man, which sold truckloads. When working on smaller games, the employees rarely feel as if their efforts are "worth it." A profit-sharing plan that ends up distributing no profits may get one game out the door but all your employees will quit before the second one is done.

______________________________________________________