Tales of the Rampant Coyote

Adventures in Indie Gaming!

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

  • Robert Basler said,

    You missed one:

    6. A healthy crunch is not unpaid.

  • Inge Rasch said,

    I like that first sentence: “Crunch is when people working on a project put forth the “extra effort.””

    It seems that crunch is often presented as a game industry exclusive. It’s not. It very common in all kinds of project organized environments. I work in a completely different industry where people jokingly starts to talk about just sleeping in the test labs, rather than going home.

    Completely agree with you though, crunch is a tool to help steer a project back on track, but easily misused as a part of poor planning. If you plan for crunch, you should probably reconsider why it’s necessary.

  • Rampant Coyote said,

    @Robert – I’d disagree with that requirement. A lot of indies and start-ups don’t get paid (or paid *reasonably*), but have a stake in the results. The stake isn’t necessarily financial… it could be an effort to change the world for the better. 🙂 But this *IS* a factor that gets abused by employers, particularly in game development. The only stake an employee has is “making their mark” and improving their resume, but employers / management puts pressure on them to act the way the game development culture has traditionally acted… the crazy effort and sacrificed and long hours poured into making “something awesome.” The thing is, that tradition came from an era where success came with very real back-end reward should the game prove successful. During the 80s and early 90s, before the big publishers really rigged the game in their favor, being a team-member of a hit game meant you could pay cash for your house with your portion of the royalties. Or better.

  • marcomon said,

    Crunch is very common in every working environment where management is weak or incompetent because crunch is the simplest way to try to hide management failures, as you correctly pointed out.
    The problem is that most managers are chosen for reasons which have nothing to do with “management”.
    In the best case hard-working is the main reason, but it has nothing to do with managing employees or planning their work: completely different skills are required. When everything falls apart the manager mandates crunch and/or blames his employees for not working hard enough.

  • Rampant Coyote said,

    Yeah, the “Peter Principle” in action. I think software companies have traditionally been where this has festered the most because managing software development *is* such a tricky beast and unlike managing other kinds of projects (even engineering projects), and so they’ve drawn management from programmers who have demonstrated superheroic ability. But that doesn’t translate to being able to lead a team or even instill that ability in others, like you said.