[game_edu] Qol, "crunch" and Education

[Mike Sellers]

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

>

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