[game_edu] Qol, "crunch" and Education

Dan Rosenthal swatjester at gmail.com
Fri Feb 4 20:29:21 EST 2011


Mike,

Great post! What about in fields where the vast majority of your students come in already on the "heroic crunch" workload because simply feel they have to in order to get hired? It's a problem we struggled with in law school -- you have hundreds of people who already are type A hard-charger personalities, taking on more and more work not because they were ordered to, but because they were simply trying to rise above their peers. Problem is, over time this accretes until students start getting dangerously overloaded, and it stratifies the pool of graduates. Basically, what happens when everyone signs up for those incredibly long hard hours, because they feel like they have to to compete?

I've been kicking around ideas for a while now about ways to prevent students from being overworked and overstressed due to occupational expectations. Most stress-relief programs schools offer that I've followed generally say things like "take breaks, manage your time, have me-time, etc." but never talk much about how you learn to draw the line.

Again, the above refers mainly to fields outside of games; I'm trying to figure out to what extent this sort of thing affects game education, but it's more of a curiosity than anything else.

-Dan

On Feb 4, 2011, at 12:29 PM, Mike Sellers wrote:


> One other note on crunch. There are three separate kinds that need to be considered:

>

> First is a quick sprint, putting in a long week or two to recover from a setback, unexpected bug, or design change in the face of an unyielding deadline.

>

> Second is lifestyle crunch. This is maybe the most common kind and the most destructive. It results from habitual underestimation due to wishful thinking all around.

>

> And third is what I'll call heroic crunch. This is often confused and conflated with lifestyle crunch, but they're entirely different. Sometimes, especially in a startup or similar situation, you knowingly take on a set of tasks that far exceed the time or resources you have to accomplish them because the reward (or even just the challenge) makes it worth it. "Heroic" here isn't a bad thing -- you could also call it challenge or adventurous crunch. Where someone says, "yeah, okay, that's crazy, but let's do it."

>

> The problem is that we confuse these all the time. We think that something will be a short sprint and it turns into a death march. Or we have executives trying to cajole employees into heroism when it's not really of their own choosing.

>

> IMO there's nothing at all wrong with signing up to work incredibly long hard hours (for a while) if you know what you're doing and why. "Slow and steady" does not always win the race, sorry. But it's when that effort becomes just how you do things on a normal basis that productivity, morale, and QoL problems quickly flood in.

>

> Mike Sellers

>

>

> On Fri, Feb 4, 2011 at 11:22 AM, Mike Sellers <mike at onlinealchemy.com> wrote:

> Very interesting discussion. Crunch is a complex phenomenon in any software business, but is highly visible in games.

>

> One thing I would suggest for those teaching students about software engineering in general and game development in particular is how to make better estimates of their work. This takes time, but is a great self- and team-check.

>

> One (educational) way to do this that I have used in industry to extremely good effect is to have team members (students) create typical schedule estimates as part of planning a project. This is fairly standard Gantt-chart stuff, but we're always dealing with unknowns that make any task estimate risky. So then expand this into 10/50/90 estimates: they have to define their most optimistic estimate (10% probability, if everything goes well), their midline (50%, should have been their initial estimate), and their conservative estimate (90% probability of completion by that time, absent a meteor hitting their computer).

>

> Then, throughout the course of the project (on a weekly or even daily basis), have them continually re-estimate their tasks. Those that they're actively working on should see the 10/50/90 estimates converge. If they don't, there's something wrong -- a task that was 3 days from being done 2 days ago, and is still 3 days from being done needs critical review.

>

> There are three great things the students or team members get out of this: first is a quantitative understanding of how their own schedule estimates differ from reality. Second, a quantitative measure of how their ability to schedule can improve (on a second short project they should be able to give better estimates of what can be done in a given time). And third is a clear and again quantitative understanding of how it is that projects get behind. Whether it's someone's laziness or being unprepared, changing or unknown requirements, unexpected bugs or design taking longer than expected, it quickly becomes clear where the sources of crunch come from.

>

> It's easy to blame designers, programmers, or execs in game studios for crunch, but the fact is they all play roles in this. Without question to me the key in avoiding crunch-as-lifestyle is sizing reachable goals to the time and resources available -- and the only way to really do this is to know, quantitatively from past experience, how accurate your task estimates are likely to be (this is still a rare thing in industry, but is incredibly useful). You can even get to the point of saying, "okay, those estimates look and feel pretty good to me. But I know from past experience that my 'looks good' estimates of ill-defined tasks need to be multiplied by 1.12 to get a historically accurate measure of how long it will really take."

>

> Armed with this, students can learn to avoid crunch whenever possible, or at least not contribute to it being a way of life.

>

> Mike Sellers

>

>

> On Fri, Feb 4, 2011 at 10:13 AM, Jose P. Zagal <jzagal at cdm.depaul.edu> wrote:

> I have a question for you, Jose, about the 40 hour work week and Ford.

> The processes there were for efficiency of assembly line workers. Fewer

> errors when workers aren't over tired. I can see the parallel between

> being more efficient when you have a good nights sleep (GGJ aftermath

> still fresh in my mind.).

>

>

> But with relatives that work in film production, I know that there are

> exceptionally long hours there and some 'crunch' to get things done on

> time. The main distinction I see is that those fields are unionized and

> there is a financial penalty in terms of overtime for poor management.

>

> Sometimes creative work necessitates long hours. But the difference here

> is that creative professionals in game development are not compensated

> at the point where those hours are incurred in the development process.

>

>

> There's a difference between occasional long hours and crunch as it is used in the game industry. In a nutshell, here's what we know (and this started with 12 years of research at Ford, but has continued in various other industries):

>

> 1. Overtime results in productivity gains, these gains are the highest in the first week and then rapidly decrease over the following weeks.

>

> 2. You need a recovery period following overtime to get back to "original" productivity. (in other words, you may get a productivity boost for 2 weeks, but you'll have to "pay" for that later on, in terms of productivity).

>

> And...in the creative industries, the numbers are actually lower. Performance begins to decline after 35 hours a week, not 40.

>

> So, yes, overtime can be used to achieve short-term goals (e.g. work a week of overtime to get that presentation ready for E3) but it must be followed by reduced time (work 30 hours a week the week after) if you want to maintain productivity.

>

> The MAIN problem when we look at educational settings is that students have a much harder time seeing (and experiencing) the loss in productivity that results from sustained overtime. Pulling an all-nighter for that one project might work (productivity boost) because you'll rest for two entire days after that project is turned in...and then you're ready for another all-nighter for the next project... As far as I know there's no school out there in which students are working overtime throughout the entire quarter/semester...

>

>

>

>

> --

> José P. Zagal

> Assistant Professor

> College of Computing and Digital Media

> DePaul University

>

> http://www.ludoliteracy.com/

> http://facsrv.cs.depaul.edu/~jzagal

>

> _______________________________________________

> game_edu mailing list

> game_edu at igda.org

> http://seven.pairlist.net/mailman/listinfo/game_edu

>

>

> _______________________________________________

> game_edu mailing list

> game_edu at igda.org

> http://seven.pairlist.net/mailman/listinfo/game_edu


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/game_edu/attachments/20110204/c52e1729/attachment.htm>


More information about the game_edu mailing list