[MUD-Dev] Crunch time

Derek Licciardi kressilac at insightbb.com
Thu Aug 7 00:42:54 CEST 2003


From: Damion Schubert
> From: Derek Licciardi

>> 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.

> I know of many programmers who would disagree - and I'm one of
> them (when I code).  I do a much better job at implementation if I
> do it in large crunchy bursts, and off-hours work is usually
> better for the really big system coding or design since you're
> less likely to be interrupted (meetings are rarely planned for
> crunch hours).

> I grant that not everyone is biologically set up to work like
> that.  Maybe it's related to the fact that my most creative times
> are at night.

> That being said, large subsystems shouldn't be done without enough
> QA time to test them, but that's another story altogether.

If you include my next sentence of that paragraph into your response
then we are essentially saying the same thing.  I wrote: "You're
asking for a quality issue by implementing full systems in crunch
mode."  My assertion was that code was not as thorough or of the
proper quality standards when coded in crunch time.  I assumed
crunch time came immediately after normal development time, coding
was continuous and the time was bordering on a death march.  Its
then that a large subsystem stands a good chance of not having
enough QA because of the lack of time crunch time represents.

Your idea of "burst" crunch time is perfectly legit.  It's actually
closer to the original idea of good crunch time versus bad IMHO.
Short bursts of crunch time can be very productive as long as there
is a change of activity or rest in between.  I'm assuming this is
the case with your statement.

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



More information about the mud-dev-archive mailing list