There are two schools of thought about crunch time--"We can't be competitive if we don't crunch" and "Studies have shown that programmers are at their most effective when they only work n hours a day." Jamie Fristrom explains why both camps are right, and details his experiences in using it sparringly.
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.
If your deadline gets pushed back just before you were supposed to hit it, it might be a death march.
If you're working overtime, and there aren't clear lists of tasks that need to be done, it might be a death march. (Example: "We need to work until this milestone is done": death march. "We need to work until this milestone is done and these are the items that remain before it will be considered finished": crunch.) Note: I'm not saying this clear list of tasks won't grow. It will. Things get forgotten, bugs get revealed, tiny features creep. But there should be a list, and it should get smaller as you progress.
If your team has shipped a game on time before, it might be a crunch. If your team has never shipped a game on time before, it might be a death march.
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:
It's nobody's fault if one person is further behind another. (Except maybe the project manager's.) Task length is unpredictable and it's not possible to perfectly level schedules so that everyone is evenly tasked.
Someone who is "done" can almost always find a way to help. Front-end programmers can do AI, and vice-versa. Modelers can texture. Programmers can script. Scripters can test. And so on. Efficient? No. Having people work outside their specialties is not efficient. Gets the game done sooner? Yes.
Forcing some to work overtime and not others can, in theory, lead to teamicide as those who are working overtime begin to resent the ones who don't. It's better for the team to hate the leads than to hate each other. (This makes it sound like we discourage voluntary overtime--people working late just because they feel like it. We don't, beyond the occasional, "It's late. Why don't you go home?")
It's worked for us so far.
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.
______________________________________________________
Read more about:
FeaturesYou May Also Like
