Apparently if I say “crunch is awesome,” it gets attention.
In response to this month’s first column, a couple of industry news sites linked to the article, and a few readers commented, on their sites and here at The Escapist. This in itself is fantastic because it prompts a dialogue I consider a core part of the column’s purpose. But it does also put me in the position of having to clarify a couple of points.
Crunch is indeed distinct from “flow.” However, the crunch process can become intent to induce group flow; it, and much of game development, exists to harness this Zen-like creative process. The problem is this phenomenon isn’t limited to programming, and when managers indulge in the flow state – which, by definition, does not allow for timely, rational decision-making – there is in effect no one at the helm. And when managers abrogate their organizational responsibilities in order to permit or share in the flow process, a project can spin out of control.
Game production lets flow run wild for a series of reasons. The first and most common excuse is “if people want to work late voluntarily, I’m not going to stop them.” It’s voluntary, right? Who am I to intercede? The problem is telling someone to go home can actually quantifiably increase the quality of his output and is therefore more efficient than allowing him to run himself ragged – as a programmer, particularly a junior one, is prone to do when running up against a problem he can’t immediately solve. Is there a difference between an isolated few late nights and a regular habit of spending more time in the office than at home? Of course. But many managers will refrain from kerbing destructive habits, to the detriment of their product, out of a disinclination to prevent workers from spending extra hours in the office.
Flow is perceived to be a necessary part of the creative process and therefore uninterruptible and beyond criticism. Uninterrupted flow leads to burnout, which leads to missed objectives, which leads to crunch, which leads to deathmarch. For these reasons, the two are indelibly intertwined, and without cracking the mythology of flow and admitting the addictiveness of the pressure-cooker crunch environment, we cannot get to the root of the attitude problem associated with poor production environments.
What’s more, many managers will refrain from interrupting flow because they understand it too well. Until relatively recently, almost all game managers came out of the ranks of whatever department they started in; artists become art leads, programmers become engineering leads. And unless a lead makes a concerted effort to study management methodologies and techniques, what they bring to the position is valuable expertise on a subject they, in large part, are no longer practicing.
The good news is the cycle can be broken. I talked to production professionals inside and outside the game industry to ferret out the No. 1 crunch reducer, and this is what they said.
“When it comes to what’s most important, I cycle back to the fact that it’s really knowing exactly where you are at and what you really have to be delivering in the end. Feedback leads to this knowledge of where you are at and iteration leads to knowing the delivery condition in its real state. Armed with that, there are many things that you can do to change process, improving all different things — but in this context of where you really are and what you really must get to.”
– Kenneth Yeast, Director of Engineering at Seven Studios and recent speaker at the IGDA Leadership Summit
Yeast provides a link to one of Seven’s most recently reviewed games, and cites the lack of overwork on the project as integral to its success and quality.
“Being realistic up front about what you can accomplish in the time permitted when planning the project. Most crunch situations I’ve been in are the result of naïveté in the early planning phase. Sometimes this is the result of over-promising while undercutting other bids during deal shopping. Or, perhaps launching on a crusade for one particular technical feature/design principle that sabotages the entire project.”
– Ralph Barbagallo, President & Owner, FLARB LLC“In most programming environments each worker has several tasks needing to be completed at any given time. These tasks are commonly from several different projects and will almost always have varying priorities. The priorities change on a daily and even hourly basis. In this situation, most workers will start working on a task and then switch to another and yet another and on and on through the course of the day. The primary effect of this is to dramatically extend the amount of time that it takes to complete each task because while Task B is being worked on, Task A is waiting! A secondary effect is that the worker’s ‘capacity’ is reduced due to inefficiencies encountered when switching from one task to another.
Overall, this factor causes delays to ripple through the project and propagate to other projects requiring that same resource. The effects are far reaching throughout the organization; it is called the Cascade Effect. When this happens, projects are delayed, requiring ‘crunch time’ or overtime to complete it. So, if I could name one element that contributes to overtime; I would say Bad Multitasking! Fix it and reduce crunch/overtime.”
– Chris Zarecki, Vice President, Viable Vision“Joel Spolsky wrote quite a bit on this subject recently. He calls it ‘evidence based scheduling’. Really, I think the big trick is to have enough of a software design so that (a) the ‘low level components’ are small enough to be reliably estimated and (b) you’re looking at enough of the system that you’re forced to confront the complexity that all your design work is trying to cleverly abstract away.”
– Brendan Drew, Research Scientist, PercepTec, Inc.“When I talked to the CTO of a mid-large sized games company (250 devs when I visited) I asked about crunch and overtime. He said that when they negotiate timelines with the IP owner they lay things out very clearly. If the owner asks for a new feature to be added then they ask in turn what existing feature is to be dropped or what is the new ship date. Of course I didn’t believe that they didn’t work constant crunch for six months when he told me that as well. Then I watched the 40-50 people streaming out on time at about 4:30 that day.”
– Glyn Heatley, Executive Producer at Thunderbird Six, former Conference Director of FuturePlay
And who did Glyn talk to? Stay tuned…
“I actually think the most important element is having management and producers on board with eliminating crunch as a priority. An awful lot of crunch flows from the top down and is intentional; remove the corporate greed (‘hey, we pay our workers the same no matter how many hours they put in, so let’s demand more hours! It’s like free money!’) and you remove an awful lot of the crunch.”
– Ian Schreiber, Visiting Professor of Game Design, Ohio State University
The final piece of the puzzle, and the key to quality of life as a whole, is, as Schreiber says, intention. At risk of sounding too much like a motivational speaker, the crunch problem, in the words of those that have solved it, boils down to three things: communication, organization and motivation. If employers in the industry commit to the emergent goal of quality of life – as they should in the interests of efficiency and quality of product – and promote the tools to achieve it, crunch is a solvable problem.
Erin Hoffman is a professional game designer, freelance writer, and hobbyist troublemaker. She moderates Gamewatch.org and fights crime on the streets by night.
