Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
August 31, 2014
arrowPress Releases
August 31, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Crunch is Good for You
by Seth Sivak on 04/24/14 01:45:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutraís community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

These kids have been pulling 60 hour weeks ever since asking to be "crunchatized." 

Work/Life balance has been a hot button issue in the game industry since back before EA Spouse. “Crunch” has become a dirty word, a word that makes engineers and artists shiver and producers hang their heads in shame. I’m here to argue that crunch, in small doses, is actually good for your team, your process, and your game.

I am not, however, advocating for prolonged crunch; months and months of 6-day weeks hurt the creative process.

­

The common opinion is that crunch is unnecessary and happens as a result of poor planning, or that it is counterproductive because work during crunch has more errors and worse quality, leading to a net-negative benefit. Like anything else, crunch can be done wrong. I believe crunch can be a way to ramp up, reprioritize, and bring your team together to complete a significant goal—as long as it is done right and not that often.

1. Pick a Goal

External groups will impose goals on the team, whether they are publishers, investors, platform holders, or something else. These are not the goals that the team should focus on. The team should factor in external goals but, ultimately, the final choice is up to the team. If the team is not invested in the goal, or if they don’t think it’s the right goal and reasonable given the available time, the entire process falls apart. Passionate people will sometimes crunch on their own because they care so much about the goal that they are motivated to push themselves independently. If possible, set a goal that motivates, excites, and challenges your team.

Goal setting is hard. Your goal must be realistic, but also aggressive enough that the team needs to push to complete it. The better the team gets at working together, the easier this will become—but don’t expect it to be perfect the first time.

2. Track Progress towards the Goal

At Proletariat, we do weekly sprints and 4-6 week milestones. We try to include 1-3 weeks of polish time that is used to iterate and fix bugs. Our philosophy is to get things into the game as quickly as possible and recognize that it will never be right the first time. We track goals weekly and get bids from members of the team to make sure that the goal still seems realistic. We almost always end up eating into the polish time, but that is also the block that is reserved for possible crunch.

If you do not track your progress, it becomes impossible to plan and set expectations around hitting the goal. This is real work and it is important, so it must be prioritized.

3. Crunch

As soon as possible, the team should decide on when they want to start crunch. Communicating this early is the fairest way to let everyone prepare. At the start, it’s important to have the tasks properly prioritized and the team members balanced. Bidding tasks is difficult and—this may sound silly—it’s important to include the person doing the work in the discussion to make sure that the planning makes sense. This also allows that person to buy-in to their tasks and call out an unrealistic workload early.

There will inevitably be a few members of the team who fall behind. It’s not their fault; it’s the nature of building this sort of product. This is a chance for other members of the team to step in and help them, to creatively solve problems and work together to hit the goal. This will serve to strengthen the team and allow members that may not work together often to have the chance to gain experience together.

The last, and probably most important part of the process, is the re-prioritization of tasks. There will be too much work to complete, even with the team pushing hard, but the goal date should not be moved. It’s time for the team to take a hard look and pick which things are absolutely needed to make the experience that the goal required and which things don’t make the cut. This is a very difficult process, but it will make the game better, more elegant, and more refined. It will also force the members of the team to separate themselves from the project enough to take an objective, holistic look at it instead of only the pieces that they are responsible for.

4. Post Mortem

After each of these milestones, it’s important to leave time for the team to recover. We usually reserve a few days to reflect on what went right and what went wrong. We take those lessons and try to refine the process for the next time around. The whole team had a chance to push themselves and each other and learn more about what they can accomplish together. This process also surfaces more issues about the game, and this down time is a chance for the team to think hard about why they chose to cut or prioritize certain features and talk through what this means for the game.

In the end, it’s healthy to push the team. It is a challenge for the people who are executing and a good forcing function on the people who are prioritizing the work. Each goal that is hit builds momentum and each one that is missed is an opportunity to learn. However, it’s important to remember that when asking the team to crunch, you’re taking them away from their friends and family, so always make sure you're doing it for the right reasons and with the right goal. 

If you’re constantly crunching then, yeah, you’re probably doing something wrong. But a well-timed crunch can be an important part of your process. Crunch doesn’t have to be terrible. The changes that go into a game during crunch are often the ones that really improve the experience in a noticeable way. Crunch can bring strengths to light, forge bonds on your team and, of course, create crucial pieces of work. At the very least, it will teach you something new about your team, your process, and your game. Who knows, you might even feel good after.  


Related Jobs

Backflip Studios
Backflip Studios — Boulder, Colorado, United States
[08.30.14]

Game Producer
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[08.30.14]

Producer - Infinity Ward
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[08.30.14]

Senior Tools Engineer - Infinity Ward
Nexon America, Inc.
Nexon America, Inc. — El Segundo , California, United States
[08.29.14]

Production Coordinator






Comments


Kelley Hecker
profile image
I'm not really understanding your point. I think you could take out the entire "Crunch" section of your post and everything would still work. You set a goal, you work towards that goal, and then you take time to reflect on the work you've done. How does designing the goal to force crunch make the result any better than if you scheduled the goal without crunch?

Seth Sivak
profile image
By pushing harder and overfilling the bucket you need to prioritize more than if you planned perfectly, forcing a more ruthless filtering of what is important. Crunching forces you to cut. Without this pressure there is no challenge to the original ideas and priorities, which could very likely be wrong since they were devised 6-8 weeks ahead of time and only on paper.

Rick Dimond
profile image
This still does not make sense to me. You are saying that you overload the team to force them to make hard choices.

Great.

Seems like that hard choice is to cut things so you *don't* need to crunch. If you are overloading the team, and spending extra time to get the extra stuff done, then you are not doing the filtering that you want.

I am all for pushing teams to achieve as much as they can. Aggressive goals are potentially good. But when that turns into them having to work extra hours because you added too much to the schedule, that still sounds like a scheduling failure to me.

Luke Groeninger
profile image
Isn't that the purpose of leadership/managers though?

It seems to me like crunching, as you describe it, would be the sign of a manager or leader who doesn't know how to do their own job, and instead forces it down on the people below them.

There are other, better ways to achieve the same goal.

Frank Washburn
profile image
If the manager/leader is the sole one making choices about what to cut, about what to push, then how does that generate buy-in for the goals? What if that manager's instincts are wrong? How is involving the whole team in that decision a bad thing?

Ian Richard
profile image
In my experience, the projects that have the best results were the ones where we made the hard "cutting" decisions early and set aside enough time for polished the changed ideas and priorities towards the end.

The projects that fall apart are the one's where we think that we can "Brute Force" our way through a project. Putting in hours is not the same as getting things done.

No amount of "hard work" will compensate for an over-scoped project and lack of well-rested employees.

Bryan Wagstaff
profile image
Crunch is usually little more than an excuse for unpaid overtime. In most places this is illegal. In the US there are specific exception for computer programmers and for managers whose primary job is oversight, but everyone else on the team (artists, animators, designers) must be paid overtime or risk legal consequences. Even if thy are paid on a salary basis they are not exempt from overtime. Some studios like to write in their employment contracts that a non-exempt position is really exempt---they discover the error when the DoL or a state employment department pays a visit.

Either hire enough people to do the job, or cut the features you dont have time for. A studio that uses 'crunch time' is a studio with bad (potentially illegal) management practices.

Christian Kulenkampff
profile image
@Kelley: I totally agree with you.

Unfortunately many good practices often only occur when there is a "crisis". One of my professors (Dr. Klaus Mentzel) postulated, that if you want to improve your processes you should look at the processes when there is a crisis. He called this transfer of good practices from times of crisis to day-to-day business "the permanent crisis" (ger. "Die permanente Krise"). Of course one should cherry-pick only the good practices.
One key aspect he often emphasized is the increased willingness to delegate responsibility in times of crisis. He assumed that especially this transfer of responsibility motivates people, not the threat/lack of time itself.

Josh Charles
profile image
I believe I understand your goal but I just don't agree with the notion that the pressure from crunching is the only way to achieve those results. Crunch is necessary to force a team to cut or get the team to challenge the original ideas and priorities? Why does it have to be necessary? There's no reason why a strong team leader can't get that response out of the team without requiring the team to work extra hours.

A team of developers can pick a goal, track progress towards that goal, and budget time accordingly to prioritize and re-prioritize features and bug squashing, in essence forcing the team to take a hard look at what stays and what gets cut, all without having to actually work longer hours and run into work/life balance issues.

When you refer to bidding tasks and having team members weigh in on the discussion to make sure the planning makes sense and that unrealistic workloads are called out at the beginning of the "polish/crunch" period - that should not be the first time those kinds of granular conversations take place. By the time the producer gets to this period, they should be able to budget those final weeks like any regular work week where the focus is on making sure the team understands how to evaluate priorities and reiterating that any concerns be communicated by the people who know best so everyone is on the same page. Depending on the scope of the project, why not have more than 1 assessment period during the timeline so that the team can refocus if necessary before they run into any major red flags at the very end that can possibly lead to crunch?

Game development is definitely messy and it's certainly not perfect. And we are all human and we make mistakes. But regularly running into crunch periods, even if it's a week or two per project, seems to me to be an issue of not address past mistakes or possibly being too conservative with time management.

Anywho, just sharing my thoughts on the matter.

Paul Wrider
profile image
"Crunching forces you to cut." No it doesn't. You're crunching because you've set unrealistic goals for a normal work week that must be completed. Thus, you work 60 - 80 hours to complete it.

"You keep using that word. I do not think it means what you think it means."

Amir Barak
profile image
http://scholar.google.co.il/scholar?q=effects+of+stress+on+body&h
l=en&as_sdt=0&as_vis=1&oi=scholart&sa=X&ei=hBNaU7PvGbSO7QbM9oGgCw
&ved=0CCcQgQMwAA

http://scholar.google.co.il/scholar?q=effects+of+overwork&hl=en&a
s_sdt=0&as_vis=1&oi=scholart&sa=X&ei=iBNaU-aMNIS27QaJnICICg&ved=0
CCkQgQMwAA

http://scholar.google.co.il/scholar?q=effects+of+overwork+on+ment
al+health&hl=en&as_sdt=0&as_vis=1&oi=scholart&sa=X&ei=qBNaU6CrCem
d7Qah5IAQ&ved=0CCkQgQMwAA

yeah, crunch is great! after all we have so much scientific evidence for that, right?? right??

****
Overworking, whether intentional or not is BAD FOR YOUR HEALTH! No product, least of all games, are worth it. Pick a goal, work towards it. If you didn't reach it in the time you allocated then stop. Rethink, iterate on the process and do again. There is no need to do more than 7 to 8 hours MAXIMUM a day, as a programmer you aren't even effective after about 6 anyway...

David Paris
profile image
Please take some time and read up on the historical reasons behind switching to a 40 hour work week. This wasn't done out of the kindness of some manager's heart, but rather that it is roughly the breakpoint above which your employee work degrades.

You might also want to read some of this stuff:

http://legacy.igda.org/why-crunch-modes-doesnt-work-six-lessons

Yama Habib
profile image
Can attest to this. In the few projects where I've been tasked as a programmer and had to crunch, I noticed a significant and steady degrade in the quality of my work leading up to and past the 8 hour mark. Past midnight, any changes I'd make would simply introduce more problems rather than fixing the ones that existed, to the point where in the next morning, after I've had a half-decent night's sleep and time to ponder issues, I'd realize that the fastest way to make progress would be to undo much of the sleep-deprived work I'd done the previous night, then continue from there.

Ryo Sasaki
profile image
This is an very interesting reference. In fact, the "short term output" section supports the article's argument: short term crunches (less than 8 weeks) increase the production output.

"If 40-hour weeks offer the most reasonable long-term arrangement for maximizing output, can we expect to get short-term gains from short periods of longer workdays or extended workweeks?
In a word, briefly. You can get more work out of more hours for several days to a couple of months, depending upon how much longer the workday is."

Edit: added quote.

Adam Bishop
profile image
Actually the 8 hour work day (and thus the 40 hour work week) was won after decades of campaigning and battles by unions. It may happen to be the case that it accords with peak output, but historically the 40 hour work week is a result of unions fighting to create a better quality of life for workers.

Martin Annander
profile image
You should read the IGDA reference for some more background, because it points out that it was in fact industrial pioneers that tried different work day lengths in order to maximise output - quality of life wasn't on their agenda.

Kelly Kleider
profile image
My understanding (which is probably flawed) is that is was a concession.
A 12 hr shift was too long (fatigue and injury) but it was nice to have only two shifts to manage. By going to 8 hrs that allows for 3 shifts and minimizes fatigue and injury.
This was all hashed out in a time when most jobs were manufacturing related rather than service.

Andrew Pellerano
profile image
I think there could be arguments for crunch despite the overwhelming evidence against it, but this article isn't one of them.

Crunch provides a brief increase in productivity that can last for 1-2 weeks and then you pay for it with a trough of less productive work that lags for a month. If you crunch longer than 2 weeks or more often than once every 6 weeks your crunch is pointlessly taxing with no measured benefit. So I could see an argument where you have a hard HARD deadline and you crunch for the two weeks leading up to it and then adjust your scheduling after the 2 weeks to account for the expected decrease in productivity as people return to a normal 40 hour work week.

This article is really about task prioritization. Here's how I prioritize my work to achieve the same effect without crunch. I sit down and put time estimates on every task. If a task is more than 8 hours it has to be broken down until it is comprised of 8 hours or less tasks. Now that I'm done estimating I double every estimate. This isn't because I'm bad at estimating, doubling is just my magic number to account for unexpected delays and POLISH TIME. Finally I stack rank the tasks in order of importance and then start making cuts until I fit into my original deadline. If the end result doesn't make sense I now have all the data to make that argument to the decision maker.

Gerald RK
profile image
I was hoping to read a little more about the social aspects of crunch.

I remember a project where the whole team crunched, including artists although it was a specific feature that had to be rewritten by the client-developers. The client guys were stressed out but having the whole team around supporting you was good for motivation. It even was good for them as well as they were able to spend time on polishing/refactoring aspects they cared about but never got time scheduled for it.

It wasn't a long crunch but afterwards we all felt a distinct sense of accomplishment and pride in our achievement that tied us together. I felt better connected to my team afterwards and although all the negative aspects of crunch were there, I was able to take something positive away from it.

Andrew Haining
profile image
You're wrong, you're part of the problem and you clearly don't have a family to go home to.

Jonathan Jennings
profile image
In regards to crunch yes I think we all have war stories, yes when you spend 15 hour days working on ANYTHING with ANYONE you build a sense of camaraderie and closeness.......or you hate your job even more depending on the people lol.

Yes you are forced to make cuts or force in as much content as you can within a short period of time which may result in the scraping of the more unnecessary features

Yes you can even come away with some knowledge, understanding of how you work under pressure , and more experience from a crunch situation .

with all that said Crunch is NOT good for you , I think small team solidarity pushes can improve bonding and help you team rapidly push your project to a better place . but those should be team lead and really team agreed.

for my first 3 months of work we worked on average 12 hour days for 3 months ...a 10 hour day was an early day in which i marveled at all the extra time I had for that day haha . let's be honest that's not nearly as bad as some devs have it . The projects in question were basically " Rescue missions" where a project with large ambitions was requested to be completed by a client in a matter of time and those involved with the planning and development were inept at best . which caused my team to have to burn the midnight oil to get the projects out the door .

the thing about crunch is unless it's an indie project or a self published project I should say , it is ALMOST ALWAYS the product of poor management . a slacking team can cause rapid crunch too but that is less likely than basically a manager or schedule builder planning out a development time line with minimal if any buffer time for polishing / testing/ etc.

Interesting article and I applaud you for presenting your opinion even if it's against the more common opinion but I really can't agree. the health , relationship, and mental horror stories I have heard crunch can turn into and even my own personal experiences have never been outweighed by the joy or solidarity I feel when meeting a project deadline .

Andrew Haining
profile image
Crunch is about extracting extra labour for your staff without pay and replacing good project planning with your employees time. It is never OK, if you take part in it or support it, you are responsible for forcing it on your colleagues. Until we understand this problem and unite, unionise against it we will continue to be exploited by our employers and then leave or be fired when we're done. Unionise now.

Frank Washburn
profile image
Seth, I think it would be helpful to many if you cleared up what exactly "crunch" at Proletariat entails - on a practical scale. I think the word crunch, as it has been used over and over in AAA, immediately brings the implication of unpaid overtime, 60-80 hour work weeks, and general despair, which from what I gather is not at all the case on your team.

Amir Barak
profile image
Upon re-reading the article I can see some further flaws with the presented logic;

"We almost always end up eating into the polish time" -> then you're doing it wrong and you're not adjusting your process.

"is the re-prioritization of tasks." -> again, you're doing it wrong, why would you re-prioritize tasks during a sprint?

"There will be too much work to complete, even with the team pushing hard" -> Because the team failed to recognize their optimal development ability. This is perpetuated because you've not adjusting sprints based on output.

" but the goal date should not be moved" -> No they shouldn't but sprints/milestones are allowed to fail. In fact by failing to achieve goals we can adjust sprints and start balancing the workload. Because the team is not gaining experience with story/task management they're spiraling into crunch each and every sprint.

"There will inevitably be a few members of the team who fall behind. Itís not their fault; itís the nature of building this sort of product. This is a chance for other members of the team to step in and help them, to creatively solve problems and work together to hit the goal. This will serve to strengthen the team and allow members that may not work together often to have the chance to gain experience together." -> this... this entire paragraph, I don't even know where to begin to be honest. What do you mean fall behind? what do you mean the nature of building this sort of product? (we're developing games not trying to stop an alien invasion or something *sigh*).

"In the end, itís healthy to push the team" -> No it isn't. It's healthy to motivate the team, not push it. Pushing is aggressive and harmful in the long run.

"If youíre constantly crunching then, yeah, youíre probably doing something wrong" -> But you are constantly crunching, you yourself have said that the team is scheduling crunch into every sprint (or almost every sprint).

"However, itís important to remember that when asking the team to crunch, youíre taking them away from their friends and family, so always make sure you're doing it for the right reasons and with the right goal. ", I'm going to use caps lock here for a second so I can make my point as clearly as possible. THERE ARE NO RIGHT REASONS FOR ASKING THIS OF PEOPLE EVER WHEN YOU ARE DEVELOPING A GAME, A F***ING GAME!!!!!!!!

"Crunch can bring strengths to light, forge bonds on your team and, of course, create crucial pieces of work" -> maybe, but you could achieve these goals with things like company picnics, family days, bonding exercises and just going out for a pint after work sometimes.

Do you think you guys could try to force a no-crunch whatsoever policy for a few sprints and instead tweak your process and workload to adjust after every sprint review? I wonder what the results would be? (positive, negative, none..?).

Ryo Sasaki
profile image
We have a hard non-crunch policy. Any crunch have to be approved by studio executive (studio size of around 200). I know some people have been crunching secretly, and those same people always do the best work. I suspect those two factors are related. I'd be interested to see some more scientific measurements in creative industry to prove me right/wrong though.

Amir Barak
profile image
"I know some people have been crunching secretly,"
This is an oxymoron. People can't crunch in secret if you know they are crunching.

What is crunching in secret anyway?
What do you mean best work?
How can you have a hard non-crunch policy when management can approve crunch?

Some of what is considered the best creative work has been performed under the influence of many many many drugs, maybe you guys should think of installing a Cocaine Cabinet or have afternoon Heroin Happy Hour?

What do you mean measurement, measurement of what exactly? There is a huge body of evidence to show the negative effects of overwork and crunch on both mental and physical health, do you really need more?

Jay Anne
profile image
I think this is a good article that will go over people's heads here. Sadly, I've noticed that most of this site's readers take the idealistic view that crunch is only ever the consequence of severe planning mistakes, rather than the more tempered view that it is a reality of an industry that will remain unpredictable, as well as being a useful optional tool when done with moderation.

James Yee
profile image
That depends entirely on your definition of "Crunch."

If you're talking a week or two of paid overtime to reach a deadline or a milestone sure, "crunch" isn't bad and can be a way to reach a short term goal. If you're pre-planning (as has been shown in some Dev houses) to purposefully schedule MONTHS of Overtime required sections of work that is not, in any way, a good thing.

Jay Anne
profile image
@James Yee
Totally agreed. That is likely the disconnect between what the article is suggesting and what commenters are reacting against.

Ryo Sasaki
profile image
I agree. The article is a good argument. However I also think it is dangerous to tell "crunch is tool you can use" given the wide abuse of crunch in the industry. We do need some over correction to get things straight.

Amir Barak
profile image
@Jay
You're coming off a bit pretentious to be honest by stating that people have an "idealistic" view and things obviously go over their heads (and I'm not sure your usage of the word 'idealistic' is correct to be honest). But let's look at what you've said near the end there;

"it is a reality of an industry that will remain unpredictable"
Almost but not quite. It is the reality of trying to predict perfectly in an industry that will remain unpredictable. How wise is it of us to keep trying to achieve a goal even though we assume that we're going to fail?

"Insanity: doing the same thing over and over again and expecting different results."
Why do people push insanity in this industry?

Yes creative endeavors are inherently unstable and hard to predict, here's a crazy thought, maybe, just maybe, instead of trying to set a stone-cold hard-dated milestone that will obviously force the team into crunch, try to figure out realistic goals for each sprint and do those. And you know what (I'm going to caps lock this as well because people seem to think that game development is a matter of life and death) IT'S ALRIGHT NOT TO HIT A MILESTONE! Just learn from your failures and figure out how to schedule better...

Jay Anne
profile image
@Amir Barak
Very true. I agree that setting immovable deadlines is bad and should be avoided whenever possible. But that right there is one example of the idealism I spoke of. Even with a completely self-published title, you can't always move deadlines. What if your indie game is set to be shown at PAX in one week and you really need to fix a showstopper bug? That is not a matter of life and death, no. But the stakes are still pretty high, and if you need to work a 50 hour week to fix that bug, it's not the end of the world.

In other words, I don't believe an ideological stance against any form of crunch is realistic or useful.

Ian Richard
profile image
I fully agree with you on immovable deadlines but the answer doesn't have to be "Work harder to put everything in". It can be "cut features and focus on the important things because we over-scaled in the first place".

My stance against crunch isn't based on idealism. I've never said that noone should never ever work overtime since nothing will ever go wrong. Sometimes *** hits the fan and you do need to put in the time.

But this the ONLY industry that I've ever worked in that says "We almost missed that deadline and lost our staff... we did nothing wrong."

I speak out against it not because I believe zero overtime should always happen.... but because that should be our goal. When we just accept that "It happens" we stop searching for ways to improve our processes.

Too many people leave this industry because it doesn't even TRY to balance work and life. That is a darn shame.

Amir Barak
profile image
There are ways to mitigate risk. Nothing you've said so far indicates that crunch is anything but a failure of management to schedule tasks and understand core feature prioritization.

I'm not saying that a week here and there of overtime is evil. I am however shocked at the suggestion that crunch should be normalized and scheduled, that's nuts... And it leads to a culture of crunching as the norm, ending up in cycles of crunch where people learn to orate such pearls as "crunching will bring you together" and "crunching is good for creativity". You can't argue with facts, overworking is bad for you, mentally and physically.

The example of a showstopping bug is disingenuous. Where are your unit and integration tests? where's your source control? who introduced a showstopping bug a week before PAX?
There are so many steps preceding the situation that I would hazard it's far more likely than not that ending up in this situation is a direct result of inexperience (to say the least); and all of this is myself included of course, I make these mistakes and I pay for them too.

Finally, excusing the practice of consistent crunching under the umbrella of realistic is harmful. We should strive to become better at our craft and this includes allowing our craft to make our lives happier, not worse. Doing anything else is an opening for abuse.

Jay Anne
profile image
@Ian Richards
I'm told that places such as lawfirms, Hollywood VFX houses work a ton of overtime. Have you worked in those industries?

@Amir Barak
The idea is to be prepared. Yes, there are hundreds of things you can do to prevent crunch, and everyone should do all of those things as long as they're reasonable. The question is, will your project still end up having to crunch? If the probability of needing to crunch is 95%, then you're better off being prepared for it. That's what this article is about. Nothing about that says that you should encourage or desire crunch.

I only picked a bug as an example. In reality, it could be one of hundreds of things. A task that went far longer than expected. A sudden emergency that forced a developer to lose out on a week of work. Unexpected surprises in quality. Unforeseen technical debt. An unexpected demand from external stakeholders. If you believe that you are so good as to avoid all of those things and avoid crunch because of it, then you are either the greatest project manager in the world or being disingenuous.

Amir Barak
profile image
I never implied I was any better (in fact I clearly stated I make time management mistakes regularly and pay for them).

But this article isn't about being prepared for crunch, this article is about having scheduled crunch and pulling in more work than possible in order to increase creativity (what the f*** does that even mean?).

I often see the argument of "but other people do it too", why do people think that's a good argument for anything?

If the probability of doing crunch is 95% then lower the probability, why do you simply accept the fact that it's alright to schedule work where it's most likely going to cause you harm?

Ian Richard
profile image
No, I haven't work in law, though I know a couple people who worked in VFX. One did lots of overtime with his company while the other did lots of pre-production and planning with pretty standard hours.

Three guesses which one is still doing VFX work.

Proper planning isn't about avoiding unforseen problems... but having enough wiggle room that they won't completely destroy your schedule when **** happens. If you've tried to fit 7 months of development into a 6 month period... you've planned to fail.

The best planning advice I've ever received was "Plan the game you can make in the time frame and cut it in half." Even if you have extra time at the end, it can be used for polishing what you have or preparing for a sequel.

Jay Anne
profile image
@Amir and Ian
Yes, all good points. I think the disconnect here is that in many cases, these things cannot change. Often times, you're handed a budget, or a product scope, or a deadline and your challenge is to figure out a way to make it work. In those cases, advice like "why not just add more schedule slack" or "why not just move the deadlines" might as well be "let them eat cake". Once again, this is the idealism that people might not understand if they haven't been a manager in the industry.

Christian Nutt
profile image
Also, Hollywood has structures and systems designed to limit overtime, and also to make it make sense. Maybe not the VFX houses (unsure) but the actual production of films, yes.

Ian Richard
profile image
@Jay
You're absolutely right. Sometime's your dealt a crap hand by the higher ups and you can only do the best you can.

But isn't that a failure from the people giving you that budget and scope?

Honestly, we're actually on the same page at this point. I understand where your coming from even if I don't agree with your conclusion.

Jay Anne
profile image
@Christian Nutt
IIRC this was one of the factors that ultimately led to the Life of Pi / Rhythm and Hues controversy. The industry keeps contract bids the same while the effective amount of work could change drastically. This might be similar to many of the scoping issues that the game industry faces.

@Ian Richard
Yes, it can be. Sometimes it's not the explicit fault of anybody, really. I remember an instance where it was the fault of fluctuations in the currency exchange rates between countries, as bizarre as that sounds. When faced with numbers that can be extremely unpredictable, sometimes having 2x or 3x the slack isn't even enough.

Ian Richard
profile image
Currency exchange rates... I never would have thought of that. I will have to keep it in mind.

Thanks.

Matthew Ahrens
profile image
I would like to argue the opposite. In companies like Google and Amazon, a 20% period of work time (taken directly from the 40 hours) is spent on goals that are sourced from the programmer/dev/worker. These are projects or work-hours not regulated, managed or hand selected from cut by the manager.

At my work (non games, but still web and software), we recently adopted this and it has been good to find the viability and best practices of working when we (devs) take a little time to self-organize away from the jira tickets and iterative sprint planning. Not only to we get to see what works and what doesn't without the pressure of a deadline, leading to better test cases and understanding of a feature, but when we get back to the tickets we have set for us we feel better about being in the strict managed style since we had a small break from it. Variety is the spice of life and you can get a lot out of a little flexibility and respect for ones personal time.

Not a study, but a link to what I am talking about:
http://lifehacker.com/5932586/make-work-feel-less-like-work-with-
the-8020-rule

David Boudreau
profile image
Interesting article, especially the line about the team helping each other out. Another interesting read is The Mythical Man-Month by Fred Brooks, which is a lot longer than this article, but that's no problem at all because you can just buy twenty three copies of the book.

Amir Barak
profile image
I salute you good sir for what is possibly one of the best comments ever made...

Stephen Etheridge
profile image
What you're describing isn't 'crunch' as we know it. Crunch has a bad name because it's inherently bad. It stresses out workers, it generates unhealthy attitudes and animosity within the workforce, it saps creative energy and ambition ('jaded developer' syndrome), it undermines family bonds and provokes breakups, it burns out employees mentally and physically (sometimes permanently) and, ultimately, it forces hundreds of people out of the industry every year*.

* Not an actual statistic, but I'd call this a conservative estimate.

'Crunch' IS shit. The practice is shit and so the word we use to describe it... is shit. Consider the phrases "bone-crunching" and "credit crunch". If you want to propose an alternative to 'crunch', you need to invent some new terminology, because nobody who has truly experienced crunch will ever get back on a bandwagon that flying that same skull-and-crossbones flag. It's like trying to promote a politician that's chosen to keep the name 'Hitler'. It doesn't matter how strong the candidate's ability or policies are, you're fighting a losing PR battle with a name like that.

TC Weidner
profile image
Crunch is just a practiced used by managers to cover up their mistakes, and/or just a way to overwork and take advantage of the workforce. Nothing more.

Stewart Spilkin
profile image
You keep using that word. I do not think it means what you think it means.

Tyrone Lawson
profile image
Seth, can I ask how old you are? And whether or not you have a family? Your article would have made perfect sense to me when I was single and 25.

Zdravko Beykov
profile image
Crunch doesn't work for me for sure - I did a game jam where I coded 30 hours in 2 days, and the next 5 days I was the most unproductive and tired person ever. It's just not sustainable and your avg. focused hours in the long term are just worse. Not to mention the sacrificed health and social life ...

Joe Program
profile image
I think I understand the appeal you're speaking to - a close knit team that really cares about the product and will go out of their way to make it excellent. However, people will do their best work on a game when they believe in it and feel ownership of it. A committed team may choose to voluntarily crunch, but scheduling crunch doesn't necessarily build a committed team.

The crunch time I feel most proud of is when I had been working on a prototype for 4 months, realized it wasn't going where I wanted it to, and scrapped it. I spent the next month working 12 hour days monday-friday, and at the end of the month we had the design that became our game. It wasn't fun, but it was a defining moment in my career.

The crunch time that was the worst was when I volunteered to take on some extra responsibilities that wasn't what I was interested in, but seemed crucial for the success of the product. These responsibilities grew until I was doing it for every product we had. Management was sympathetic, but didn't have money or time to find someone else to take over for me. There were so many other obstacles to commercialization that my effort made little difference in the long run.

[User Banned]
profile image
This user violated Gamasutraís Comment Guidelines and has been banned.

Shea Rutsatz
profile image
I don't like it when crunch is referred to as a "tool". It should be a last resort.

Clinton Keith
profile image
Sometimes people teams crunch for a short period of time because they are passionate about doing something and they are focused on that. That can be good. But reversing the logic and saying it's good to crunch because it creates focus is like saying "I'm going to make people smile so that they become happy".

But growing passion and focus is much harder than announcing to employees that "we're working this weekend".


none
 
Comment: