Good Crunch and Bad Crunch

Posted by Rampant Coyote on August 21, 2015

Crunch is when people working on a project put forth the “extra effort.” It’s long hours, late nights, sacrificed weekends, and often heightened tempers. I’ve done my share of crunch, both inside and outside the games industry. I’ve done crunch as a game developer both as a full-time employee and as an indie. I could perhaps make the argument that as a part-time indie who makes games as a side job, all I do is crunch. But there are ways to manage that.

With arguments going around once again about the evils of crunch time, I thought I’d posit that there is actually such a thing as “good crunch.” In fact, it might be best to talk about good crunch first, because bad crunch is pretty much defined as “any kind of crunch that isn’t the good kind.” Or something.

“Good Crunch”

Crunch time, in my mind, is that period where extra effort is needed. It happens. Crunching for the last couple of weeks before a major milestone?  For games, I suggest that this kind of crunch might be unavoidable. There are two factors that multiply together to make this a reality in a healthy environment.

#1 – Game developers are invested in their work (and, theoretically, have a stake in its success). This is how it often was in the old days, and this is how it often is in the indie world. So the developers themselves are self-motivated to make sure what they are making is of highest quality possible.

#2 – Game development is a somewhat open-ended endeavor: Games are never really “done.” Just shipped. But up to a point, a little extra effort can make positive improvement in the title. And… in a competitive, hit-driven environment, this might be what the game needs to stand out at a trade show, for a Kickstarter pitch, or a release.

And let’s face it… crap happens, even in a perfectly managed situation. If the situation calls for a “crunch” due to being behind schedule in some way,  in a healthy environment this should be accompanied by a long, hard look at scope and requirements. Ideally, the goal post should be moved back a bit as well as the developers pouring on the coal to get things back on track. In other words, when things start getting behind schedule, crunch is only a tool to deal with immediate symptoms, and another cure for the fundamental problem must be found in conjunction with any crunch.

 

“Bad Crunch”

But there’s a dark side. We know about some of that. Management abusing developers. Mandating crunch. Using crunch to paper over management failures. That kind of thing.

When you have a company that operates in a mode where that is the rule rather than the exception, something is horribly wrong. When 60 hours minimum is mandated for weeks or months on end (been there), something is badly, badly broken. When I hear people going off on “crunch” in the industry, that’s what I think of. That is a failure of management, and an abuse of employees.

Worse than that, crunch mode is something that is counterproductive after a relatively short time. Sure, some developers are machines that can operate at 60 hours a week for months on end with no drop in performance (or so I hear…), but most people can’t do that. In fact, within a week or two, most people’s productivity during extended hours begins to decline, in many cases dropping down below their performance during normal hours. Crunch is supposed to be “extra effort,” and it can only work (if at all) when it truly is “extra.”

When the developers are judged by the amount they crunch – showing “dedication to the project” or whatnot – then things go bad really quickly. That doesn’t encourage good work or dedication, it encourages visibility at the office at long hours; simply butts occupying chairs. It may damage some tender but vague ideals of “fairness,” but ultimately it has to be a meritocracy — how much every person is contributing and producing, regardless of extra hours worked beyond the required 40 (or less, in the indie environment).

 

“Healthy Crunch” vs “Unhealthy Crunch”

Maybe calling crunch “good” is pushing things a bit too far, so I’ll call instead call it “healthy.” A healthy crunch is one that occurs in a team that has a healthy, sustainable approach to doing business.

1. A healthy crunch is fueled by passion. An unhealthy crunch is used as a proxy for passion.
2. A healthy crunch is developer-driven as a tool to accomplish objectives. An unhealthy crunch is an objective unto itself and driven by management.
3. A healthy crunch is short. Anything longer than a couple of weeks at a stretch should be considered unhealthy by default.
4. A healthy crunch is an exception to the rule, reserved for emergencies or major milestones. If it’s a frequently- or regularly-applied tool, it no longer represents “exceptional effort” and not only loses its effectiveness, it becomes downright unhealthy.
5. If milestones cannot be reasonably achieved without any crunch whatsoever, the entire project is unhealthy.

In moderation, in certain periods, a little extra “oomph” for a couple of weeks here and there can be a positive experience. It can be used for a quick sprint for a milestone. It can be used to build momentum, which can be critical for morale during those long, dark mid-stages of development where a lot of work yields little apparent results. And – in conjunction with bigger, better tools – it can be used on an emergency basis to get a schedule back on track. But in every case, this “healthy crunch” is something that developers must do on their own.

Filed Under: Biz, Production - Comments: 5 Comments to Read



top