[MUD-Dev] Crunch time

[Sean Kelly]

(this is a bit of a soapbox topic of mine as well, so please forgive the
strong language)

J C Lawrence wrote:
> On Wed, 30 Jul 2003 09:13:00 -0400
> Yannick Jean <Yannick.Jean at meq.gouv.qc.ca> wrote:

>> The main reasons why the gaming industry is such a mess when it
>> comes to managing large project is that it's still employing
>> mostly geeks, in both high or low positions. Geeks, great as they
>> are for working days and night for your project, are notoriously
>> atrocious at planning and keeping tight schedule.  Give me a
>> ruthless, cold-blooded, project manager and a full staff of "8 to
>> 5" workers who got a life and a family at home and I'll give you
>> MMORPG on time, on budget and with a stable codebase.

I disagree.  There are geeks who are able to see the "big picture"
and who are able to assess problems accurately and meet those
assessments on time.  There are also project managers who are
terrible at communication, delegation, and time management.  That is
to say, the qualities that makes someone good or bad at these things
are qualities completely separate from technical skill.  Personally,
I believe it's as much the programmer's responsibility to possess
these skills as it is the project manager's.  If either side is
lacking, problems will occur.

There was an excellent editorial in the July 2003 edition of C/C++
User's Journal on responsibility for product quality.  Track it down
if you can.  I think it applies equally to the topic at hand.

> A large element is how well the problem space is known before
> hand, as well as how well defined it is.  In the game arena both
> tend to be rapidly shifting sands well into the development
> process.  You're inventing the field, raw CS-work, as you go
> along, _and_ and a result defining the game definition as a
> product of the capabilities you've just invented.  If you attempt
> to refute that fact and pick your absolutes early in the process
> you end up shipping a game using three to five year old technology
> -- something the market doesn't tend to relish.

> This is rather different than most business software development
> where the field and the technologies used as well developed, well
> explored, and well known.

I disagree.  The game industry and other industries face the same
challenges: changing technology, internal politics, bad management,
changind consumer demand, etc.  And the game industry is not alone
in its curse of bad planning, bad management, or feature
creep... though it's more common there because of the popular belief
that game creation is somehow not a business so much as an artistic
process.

> Is it really all that bad and chaotic?  No.  It just tries to be
> fairly aggressively, and there are strong forces encouraging it.
> Strong forces that you >need< to regularly give in to, to produce
> the product quality that is required.  Feature and technology
> creep during a product development cycle is s simple fact of life
> that you live with and try to manage reasonably.  And it is a
> race.  At some point you start drawing lines in the sand and
> saying,

>   "If we don't stop here we're going to be forever chasing the
>   next Great Thing!"

> and so you go into crunch mode so you can ship the bloody thing
> before the background technology changes so much that not
> continuing to play catch-up was stupid.

> Whaddya want, nice predictable technology evolution cycles or
> something?

No reason why not.  Feature creep is the result of unrestrained
techno-fetishism, and if it results in dates slipping that is the
result of bad planning.  I understand that consumers are fickle, but
I can't think of a single game in my top ten that was anywhere near
the bleeding edge.  Look at Diablo 2 for goodness sake.  If things
are so disorganized that sand-lines are being drawn then the
disaster isn't looming it's already happened.

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