I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the eleventh episode on crunch and how it damages a project:
Welcome to the Adventure Mechanics Side Quest. I'm Chandler. I haven't been able to get much done on Cartogratour over the last month and a half, and it's not due to lack of passion on my part. Over the that last chunk of time, I have been knee-deep in work crunch, for a variety of reasons. With work taking up all my spare time and creative energy, little has been left for game development. Instead of just complaining about my latest foray into crunch and how unfair it is, I'm going to go over why crunch is bad, and not just from the perspective of the people going through it.
I'm sure you've heard about crunch, but what do I mean when I say crunch? Well, crunch is an intensive effort over an extended period on a given project. That means that you could be crunching on a project that you're only dedicating some time per week on. In most cases, though, it's typically associated with working inordinate hours on something, often to the detriment of work/life balance. Crunch means that you're working harder and longer on a project than you can comfortably accomodate.
Now let's talk the human cost of crunch-time. When you're crunching, you're not taking care of yourself as well as you do when you aren't crunching on a project. That dentist appointment? You don't have time for that, you're crunching. Need to workout? Tough, you're either working while working out, or you're just not going to have time to work out. This push to get the project, or thing, or whatever, requires you to set aside other things in your life to get closer to that finish line. That's not only going to be a cost you'll have to pay later, but it may also be something that you'll have to pay during crunch, anyhow. Crunch will end up just wearing down everyone working on the project. And with people worn down, quality will suffer.
Why do I say quality will suffer? Well, I've been subjected to crunch twice this year alone (thank you poor management!) and I have seen what work "quality" comes out of crunch. It's frankly subpar. Now, I'm not throwing my coworkers under the bus, far from it. I am just gauging their output. Sure, the first week is okay, but the longer the crunch drags on, the worse the code becomes when it eventually gets checked in. And I do mean eventually. On a normal, non-crunch day, my team can commit multiple times, no sweat. During a crunch, though, some days may be commit-free. To be fair, that may be because of things beyond their control, such as a poorly defined tickets or ones that are ginormous. On the other hand, those also indicate that the project wasn't well defined before setting the team loose on it. Worse yet, it sets up the team for failure. A poorly planned project will absolutely waste precious time and end up delaying the project, despite how much project planners may argue to the contrary. As the old addage goes, failure to plan is planning to fail.
But let's say that the project was planned out in a sane fashion. Enough time was alloted, at least according to initial estimates. One delay leads to another, and you're staring down crunch again to get back on track. This may be tempting, but the initial crunch to get back on track will more often lead to burnt out people and, paradoxically, less work done per hour put into the project going forward. Moreover, when a person gets burnt out from crunch, it takes more time for them to recover from the crunch itself. It depends from person to person, but from what I've seen, crunch may be linear, but recovery time is geometric. What do I mean by this? For each day someone is crunched to burnout, you'll need to double the number of days needed for recovery. That doesn't mean that they'll necessarily need to completely off work, but they'll need a lower workload to take care of themselves and have time to reset. If crunch happens too often, then the team will begin losing expertise and members. That shouldn't be worth it, but I know some managers are willing to make that sacrifice to the team to get a project done. Thankfully for me, I haven't been in that situation. Losing team members to crunch, especially during crunch time, is a recipe for disaster. The crunch effectively becomes a dreaded death march.
If you're not familiar with the term, I envy you. A death march is when most people, if not everyone, is crunching for months on end. The team may be smaller from attrition, but new people aren't brought on to replace the losses, since that would take even more talent away from the project to bring them up to speed. So everyone just crunches a bit more to make up for the losses incurred by crunching. Obviously this isn't a good place to be. Bugs normally caught, handled and resolved are passed by or, worse yet, allowed to persist in the product. There's simply not enough time to resolve them and continue to add new features, at least that's the perception. Those external pressures aren't going away any times soon, so why not let those relatively benign bugs through and tackle them after release? Nevermind the fact that these bugs will damage sales in the first place. Needless to say, but once a project is in a death march, it's only a matter of time before a collapse. It's only a question of whether the project finishes or the team breaks first.
What I've said so far could apply to any software project. What makes making games unique? The culture. Everyone is hyped to high heavens for the upcoming game and want it NOW. Management sees the dollars slipping by the longer it takes to push out that new game, so they're pushing as hard as possible on the developers to get it done. They claim that overtime isn't required, but if you're a contractor on a game and don't do overtime, you're not likely to have your contract renewed. This leads to an extremely unenviable position of crunch or get fired. Talk about stressful. That speaks volume to both the concept of contractors and salaries, but I digress. Numerous exposes have come out over the last couple of years about crunch and how it ends up sucking the souls out of teams and leads to some extremely toxic situations to work in. Despite the exposure to this, we as gamers still demand to have games ever sooner with more and more polish. We are part of the vicious cycle of crunch and death marches at game studios. I'm not putting myself above this, either. I'd be remiss if I said that I didn't get antsy when a game I was looking forward to was delayed. One thing to keep in mind when a studio announces a delay, though, is that it's giving the team behind it time to put on the finishing touches on their game. I know the Miyamoto quote, "A delayed game is eventually good, a bad game is bad forever," no longer really applies in our current world of massive day one patches and "evergreen" games, but at the same time, giving a game time to put it's best foot forward is important.
Obviously I'm still a bit salty about having to go through crunch yet again this year. Hopefully I've given you insight on what crunch is, why it's a problem and why patience is going to make up for getting what you want a bit later. As always, if you have any questions, comments or suggestions, reach out on twitter. My handle is @jcsirron. This has been the Adventure Mechanics Side Quest, and I'm Chandler. I'll talk with you next time.
