[MUD-Dev] Crunch time

[Derek Licciardi]

From: Amanda Walker
> On Thursday, July 31, 2003, at 10:28  PM, ceo wrote:

> Back to "crunch time" for a moment.

> There's good crunch and bad crunch.

> I like "good crunch".  I'm reasonably distractable, so I actually
> do my best work when I am feeling some time pressure that can keep
> me in the hyperfocus "zone" while I work.  I am definitely one of
> those people for whom it can be said, "if it weren't for the last
> minute, nothing would ever get done."  I'll eat the
> company-provided pizza and drink the company-provided caffeine,
> and get more productive hours out of the day.  I've pulled some
> amazingly large rabbits out of very small hats in my time, and a
> certain amount of pressure serves as a useful motivatiing factor.

> I have come to hate "bad crunch".  Death marches do not get
> products out any faster, or with any higher quality.  Quite the
> opposite.  I've been part of several death marches where it would
> have been much better for all concerned to stop, declare the
> current product "a useful research prototype that taught us a lot
> of things", and do it over from scratch with the newly acquired
> knowledge factored in.

> I'll add a book to Tamzen's list: "Deadline", by Tom DiMarco.

Every project is going to have some degree of crunch time.  Every
project I have worked on forgot about the crossing of the t's and
the dotting of the i's that are so important in a finished product.
Like others have said, crunch time when you're so close to the end
result that you can smell it, is good crunch time.

I believe that large sub-system specifications that are not yet
implemented have no business being implemented in crunch time.  If
you feel you're getting to a crunch point and your combat system or
player housing system is not yet in the game, you should consider
delaying the game or leaving the sub system out.  You're asking for
a quality issue by implementing full systems in crunch mode.  The
difference between these death marches and the good crunch is that
you're primarily fighting bugs and other little fixes in good
crunch.  Success is fast coming with each bug squashed and momentum
is not hard to keep up because of that success.  This is a
completely different mindset from just beginning to program a given
subsystem in crunch mode.  To my eyes, the trick is to minimize
crunch time as much as possible, but like everything else in life,
realize that crunch time in moderation can be a good thing.  Just be
sure that all of your critical game mechanics, models, art, story
and code are created in normal time when well rested people can
think rationally about how to implement a design.  Crunch time
supports short bursts of creativity and concentration which is a
perfect fit for hunting down bugs, texture anomolies, animation
glitches, ... and squashing them.

Derek
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev