crunch mode

In article <cn6393$8pj$1@news1.zwoll1.ov.home.nl>,
"Skybuck Flying" <nospam@hotmail.com> wrote:

> What exactly is crunch mode ?
>
> I think they mean a period in which everybody works really hard and knows
> what to do/make ?
>
> Is that right ?

Partially. It typically happens when management has spent a fair bit of
the development cylce saying "we'll deal with that later", then "later"
comes. Now there's a looming deadline, and far more work to do than
could ever be humanly done by the staff available, and management
somehow expects the workers to put in really long hours under very
stressful conditions in order to complete the task.

Sometimes, with the younger kids, it works

--
Please take off your shoes before arriving at my in-box.
I will not, no matter how "good" the deal, patronise any business which sends
unsolicited commercial e-mail or that advertises in discussion newsgroups.

What exactly is crunch mode ?

I think they mean a period in which everybody works really hard and knows
what to do/make ?

Is that right ?

Bye,
Skybuck.

There's a good description here:
http://en.wikipedia.org/wiki/Game_pr...ng#Crunch_time

Paul Sinnett wrote:
> There's a good description here:
> http://en.wikipedia.org/wiki/Game_pr...ng#Crunch_time

Of course, some companies (not just in gaming) run in a continuous burn-mode
where it's always crunch time.
http://www.gamespot.com/news/2004/11...s_6112998.html

I guess that's good (for management) so long as they can keep replacing the
bodies. (See also Death March Projects.
http://en.wikipedia.org/wiki/Death_march)

--
Ron Sharp.
http://home.primus.ca/~ronsharp/

Android Cat wrote:

> Paul Sinnett wrote:

> > There's a good description here:
> > http://en.wikipedia.org/wiki/Game_pr...ng#Crunch_time

Insofar as Wikipedia is turning out to be a very reliable and accurate
encyclopedia, it's amazing they list "crunch time" under game programming,
not programming in general. Microsoft crunched to produce WinNT, for
example.

> I guess that's good (for management) so long as they can keep replacing
the
> bodies. (See also Death March Projects.
> http://en.wikipedia.org/wiki/Death_march)

Some bad practices management cannot get away with, but some they can
whitewash, to appear good and healthy. Look at outsourcing.

> Of course, some companies (not just in gaming) run in a continuous
burn-mode
> where it's always crunch time.
> http://www.gamespot.com/news/2004/11...s_6112998.html

It appears EA thought that chronic overtime could be whitewashed.

In the book /Slack/, Tom DeMarco tells an anecdote of consulting to a
business programming shop. They showed him a pie chart of their budget, and
he asked "where is turnover?"

The cost of hiring and on-the-job training, after people burn out and quit,
had been hidden by spreading it into the other sectors of development (R&D,
testing, admin, market research, etc.).

Overtime shouldn't appear on the chart - it should be eliminated. It causes
bugs.

My post "Agile Game Development" referred to "crunch mode" obliquely. I
intend never to experience it in games.

Over time, game projects grow a huge "decompression debt" of easily-
fixed bugs. Shipping a game requires an early feature-freeze and then a
very long party to stomp insects.

The fix requires small, easy adjustments to the entire lifecycle, including
a zero-tolerance for any bugs, and automated tests at all levels.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

Android Cat wrote:

> Of course, some companies (not just in gaming) run in a continuous
burn-mode
> where it's always crunch time.
> http://www.gamespot.com/news/2004/11...s_6112998.html

http://ars.userfriendly.org/cartoons/?id=20041114

;-)

Oh, on the business side, a lawyer asked USENET recently if any former
Seibel employees had any information about unpaid overtime, too.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

Phlip wrote:
> It appears EA thought that chronic overtime could be whitewashed.

Sometimes you eventually get a weird corporate culture where it's not even
directly driven by management. All those strange looks you get from
everyone else when you leave the office before 7pm is unnerving.

> In the book /Slack/, Tom DeMarco tells an anecdote of consulting to a
> business programming shop. They showed him a pie chart of their
> budget, and he asked "where is turnover?"
>
> The cost of hiring and on-the-job training, after people burn out and
> quit, had been hidden by spreading it into the other sectors of
> development (R&D, testing, admin, market research, etc.).
>
> Overtime shouldn't appear on the chart - it should be eliminated. It
> causes bugs.

Overtime when it's a few hours here and there as unexpectedly needed isn't a
problem--it's just life.

Extreme Overtime also happens, but in the "we fucked up badly" catergory.
Management should always realize that when they use it, they're directly
tapping loyalty, enthusiasm, pride, energy, creativity, eventually health.
That's a cost, and a lot higher than most seem to know/care. (Bringing in
beer and pizza, or taking people out to the arcade doesn't cover it.) It
also gets much worse as time goes on when you keep trying to get 170% from
people after you've used up their energy, enthusiasm and loyalty.

> My post "Agile Game Development" referred to "crunch mode" obliquely.
> I intend never to experience it in games.
>
> Over time, game projects grow a huge "decompression debt" of
> easily- fixed bugs. Shipping a game requires an early
> feature-freeze and then a very long party to stomp insects.
>
> The fix requires small, easy adjustments to the entire lifecycle,
> including a zero-tolerance for any bugs, and automated tests at all
> levels.

I fished it out of the language war posts and read it. It sounds very good
and sensible. As always, making it work is the tricky part!

I like zero-tolerance for bugs as a customer of games. Installing a huge
patches for a game a couple months (or weeks) later is annoying. Also, with
a good game, I might fish it out, re-install and play it again after a few
years. Bringing it back up to date (and re-registering it!) is annoying at
best, and impossible at worst if the company is gone or they've completely
dropped the game.

As a developer, I know that after coming off the crunch time to nail the
last no-ship bug, re-establishing momentum to fix the rest of the bugs and
get a properly QA'ed patch out the door is extremely hard.

From the project management side, ignoring bugs until the end makes schedule
tracking a joke. It's pointless to break a project down into weeks and days
of tasks if you're continually sweeping an unknown-sized time-debt under the
QA and bug-fixing part of the schedule. It's much easier to run QA in
parallel with development than at the end, and when you hit the real Must
Ship deadline, it's easier to make the tough calls on what to drop.

--
Ron Sharp.

Phlip wrote:
> Android Cat wrote:
>>
>
> Oh, on the business side, a lawyer asked USENET recently if any former
> Seibel employees had any information about unpaid overtime, too.

Strange you should mention Seibel. Do I know you from somewhere? (Never
worked for them, but they "bought with extreme prejudice" a company I was
at.)

--
Ron Sharp.

Android Cat wrote:

> ...beer and pizza...

<skid to a halt>

Wait a minute! I /like/ overtime!!

> I like zero-tolerance for bugs as a customer of games. Installing a huge
> patches for a game a couple months (or weeks) later is annoying.

Oookay. I mean zero tolerance from day one. If the code has a single bug,
stop the line and fix it immediately. This behavior grows both team
awareness of code's true quality, and it grows test fixtures, rigs, and
levels to surround the bug loci and powerfully resist them.

If a schedule is a goal and not an estimate, then hiding the bug count keeps
reality looking like the estimate.

> From the project management side, ignoring bugs until the end makes
schedule
> tracking a joke. It's pointless to break a project down into weeks and
days
> of tasks if you're continually sweeping an unknown-sized time-debt under
the
> QA and bug-fixing part of the schedule. It's much easier to run QA in
> parallel with development than at the end, and when you hit the real Must
> Ship deadline, it's easier to make the tough calls on what to drop.

I did the "ignore all the easy bugs until last" thing for many years, but
only on single-engineer projects. Games are huge, and I think we agree that
delayed integration is causing bug tolerance, and splitting teams up by
function is causing delayed integration.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

Android Cat wrote:

> Strange you should mention Seibel. Do I know you from somewhere?

Just my rampant seething anti-Seibel zealotry on the 'net...

> (Never
> worked for them, but they "bought with extreme prejudice" a company I was
> at.)

Ah, one of those "we get all your customers, and we put all your assets out
for a yard sale" deals. ;-)

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces