How is Crunch Time Avoidable?

A recent post by Keira Peney got me thinking about crunch time. One of Keira’s points is that managers need to work to avoid crunch time. But I’m not sure that’s where it should start. It’s a losing battle from the trenches, because from the perspective of the company, crunch time works. It’s only when we bring the perspective of the individual into the picture that the problem arises.

The trouble comes at the very beginning of a project, long before most of the team is even on the job. It happens quietly and without fuss.

Attacking the Time Estimates

Let’s look at engineering. Game company engineers are not inferior to programmers in other industries. An experienced game engineer can create as good a time estimate as an engineer in another industry. We all know that no estimate can be perfect, but … if the game industry’s problem were just about flawed estimates, then every software company should have similar crunch issues to the gaming industry. (They don’t, in general.) So what happened? Someone cut the engineer’s time estimate.

Snipping the time estimate is easy for a manager to do. They can do it in such a way that they don’t even feel like they’re doing something bad. Hell, they usually feel good about how they’ve reined in the project’s budget. At least at first.

The trick is to cut something nobody is paying attention to right now. For instance, nobody will notice if a manager trims the beta from six months to two months. At least, they won’t notice early in the project. But later, when they do realize what’s happened, everyone will agree that a six month beta is mandatory. Since the budget has already been finalized, that means everybody just has to get done four months faster so that there’s time for the beta! Four months of crunch time for everybody!

Other easy places to cut: QA passes and bug-fixing time between each milestone, padding time to account for unexpected surprises, art revision time to rework content from contractors. Attacking these boring, tedious parts of the schedule is infinitely easier than cutting down the schedule the right way by cutting features from the game. Everybody on the team squawks and squabbles and gets demoralized when you tell them there’s no time for Crafting, but nobody cries when you cut bug-fixing time from the schedule. Who wants to fix bugs anyway?

Crunch Time Works

The trouble is that, although we often create elaborate explanations about why crunch time doesn’t help a game, it clearly does work in the short term. EA didn’t create a culture of permanent crunch time — and become incredibly rich — by mistake.

For perhaps a year, you can get more work out of your people by grinding them up. It doesn’t work forever, but over the period of, say, an expansion pack? Absolutely. Later, these people burn out and quit the industry. But you can hire more because there’s tons of people who really want to work in game development. You can pay them squat, abuse them for a few years, and let them leave. In fact, in many areas of game development, the economics seem to demand that you do just that.

Economic (Dis)-incentives

Every mainstream game team does this, to some extent. Publishers demand amazing games on shoestring budgets. If your game company doesn’t force slave labor out of their team, some other company will.

For a company like EA, I don’t know why they would ever stop crunching. They can create tons of reasonable-quality games while paying people terrible wages. They are amazingly successful, monetarily. You can’t deny that it works.

But ahh, MMOs are a bit different from your average FPS game, aren’t they? For one thing, they take 3 to 5 years to make, which means if you burn your people out every year, you notice the productivity hit whenever you have to train up new people. And because the project is so long, you can get into morale issues: the team morale can get so amazingly low after a year or two of crunch time that the entire project can easily disintegrate. You can lose everything by over-crunching an MMO.

So in a way, MMOs are safe havens. Smart MMO companies don’t want to perma-crunch their MMO developers. They wait until the home stretch — the last year — and then they crunch them to jelly. But hey, the employees at least got a few years of non-crunch-time work out of it first. Maybe they should feel lucky.

Fixing It

Fixing it has to happen at the corporate-culture level. If your company is content to be a faceless corporation with constantly-changing underlings, then there’s no incentive not to grind people up. A culture that values longevity is a good starting point.

Longevity can bring its own rewards. The best games come out of teams with a lot of experienced team members. But on the other hand, in order to get longevity, your company has to somehow survive long enough to reach old age. If you don’t crunch in the mean time, how are you going to meet publishers’ insane demands? That’s the question you have to answer, at a company level, before crunch time can end.

It is my firm hope — not quite a firm belief, because I have yet to see it first hand — but a hope that it’s really true: that having a team full of folks with 5+ years of experience is much more efficient than having a team full of brand new folks who are working twice as many hours. I can’t prove this is true. But I hope it is.

Other Venues

Crunch is a hard problem to solve for traditional games. It’s not something a middle manager can just fix unless they’re ready to have some epic battles with the senior staff.

The traditional answer to this problem is a union. I don’t think we’ll see a game developer’s union for another decade or two, because the job roles are too variable to create much common ground.

But there is an easier avenue. There are new audiences for games, like XBLA and Kongregate. These don’t yet have the same baggage as mainstream games do, so it’s a bit easier to avoid crunch time. On the other hand, these new niches don’t have a lot of well-defined genres or conventions, either, so the risk of screwing up is very high. But nothing worth doing is without risk.

This entry was posted in Production. Bookmark the permalink.

9 Responses to How is Crunch Time Avoidable?

  1. robusticus says:

    I wouldn’t hold up EA as an example any more. Losing $400 million with a market cap roughly double your nearest competitor’s, who is turning a $500 million profit, means a whole lotta billions will be shifting away from EA in the next 12 months. Especially when said competitor is now bringing in significantly more revenue. That’s ultimately what their crunch time culture has sown, a crumbling empire.

    I always say to do estimates by lifecycle phase. Don’t estimate coding until the design is done (or 90%), testing until coding is done, etc. I prefer to allocate the same number of hours to QA as were given to coding. The estimates tend to be very accurate that way but difficult to convince people that you can’t estimate everything up front. Otherwise you’re just going the 3 weeks/6 weeks route for small/big projects.

    As for cutting QA, well, you don’t want the reputation of Acclaim or the “bring out the gimp” theme, eh? It’s ok, your users will test for you, right? And smear your name all over the internetz.

  2. Eric says:

    That’s a very good point about EA.

    I also insist on having a more-or-less complete design doc before creating engineering estimates. Otherwise it’s just a WAG!

  3. Keira says:

    Thanks for the feedback. Most of my experience is with smaller/indie companies, so a behemoth like EA it’s probably harder to negotiate with.

    I do think, however, that on the whole skilled programers/designers are going to be making more of a name for themselves, and there is going to be a lot more competition in the marketplace. Hopefully this will lead to an increase in quality, rather than trying to cut overheads. I’m sure there will be companies trying it both ways, but on the whole I would guess the ones that look after their employees will do better.

  4. Pingback: Write the Game » Friday Link Love

  5. Mike says:

    One of our engineers left his old company because of the excess amount of crunch. He’s a very senior engineer, and his departure probably cost that previous company a lot.

    At GDC one evening, I was talking to a recruiter from another major game company. I was interested in talking to some of their engineers to network a bit–we so rarely get to meet anyone that can’t come to our desk! But I couldn’t, because they were all back at the office crunching.

  6. Babs says:

    I just had an interesting meeting on our game. I was baffled by the statement that time equated with quality. Since I’m a firm believer in doing things right the first time and not relying on QA to be the benchmark of individual quality, I was completely stymied.

    Perceiving that one has a choice of either meeting a deadline or making a quality product is what perpetuates things like crunch time. It’s not just management that needs to shift expectations, it’s design teams that are so used to doing things “the old way” that they can’t comprehend what a little nip and tuck can do for them in the long run. These days, there is no apple cart in any industry that doesn’t need some upsetting in order to make cider – and games are at the place in their lifespan where they either become business-like or they fail.

    That doesn’t mean the fun needs to come out of the jobs, but that certainly means they need to understand that crunch only hurts their own pockets. No one works to lose money but that’s essentially what crunch is all about. It is devastating at a personal and corporate level.

    I agree with Keira that a more skilled marketplace will change certain aspects of how games hire their staff but if management isn’t turning over (or having deep, meaningful revelations over dinner) the effectiveness will be mitigated. As young an industry as gaming is, management doesn’t turn over as quickly as it would in, say, the Xerox culture. A businessman running a company of designers is radically different than a gamer running a company of designers.

    Why is Scrum such a buzzword right now for us? Because we suck at managing both projects and time. Nobody wants to crunch anymore but nobody knows how to stop it. To me, it’s not that hard a task. I’ve done this in other industries (including the ubiquitous entertainment industry). It’s not painless but it works. Whether its Scrum or any other kind of method, it requires a very strong leader who is open to tweaking the very systems meant to tweak the broken battlefield. And it requires a team willing to “suffer” a few hours between 9am and 5pm to avoid having to work from 5pm to midnight.

  7. I’ve always thought that the origin of crunch time was probably some manager seeing the fact that some people stayed late and thinking, “I should count that into the schedule!” There are a lot of reasons why people will willingly stay late: they are enthusiastic about the work, they want to try something out, or they are mildly autistic and get hyper-focused on the task at hand.

    When I was working at 3DO, I saw both sides of the coin. I loved M59 and willingly stayed late and worked holidays and weekends to make it better. On my next project, crunch became a necessity because we had only a few months to do the project, in true 3DO style. I grew to hate the project, even though I wasn’t really working more hours than I put into M59. There’s a world of difference between “I want to do this!” and “I have to do this….”

  8. Pingback: Job Prospects: Poor at Kill Ten Rats

  9. darkbhudda says:

    I work for an engineering company and I see schedules being unrealistically slashed all the time.

    My favourite overheard conversations when it comes to managers and schedules are:

    Manager: “Why do you have that 2 week dip in the schedule?”
    Scheduler: “That’s the Christmas holiday period. You volunteering to work over Christmas?”

    Manager: “I’ve fixed your schedule and saved months of time.”
    Scheduler checks new schedule.
    Scheduler: “You applied the wrong calendar. You’ve now got everyone working 24 hours a day, 7 days a week.”