RE: Managing "Designers disgust". RE: cheating

["Brandon J. Van Every" <vanevery at indiegamedesign dot com>]

From: Jakob Ilves [mailto:illvilja@yahoo.com]
>
> So, as a hobby hacker, by strongly handling future concerns
> one gets a win ONLY if one has strong
> immunity against the "designers disgust".  That is, being
> very (extremely?) patient and persistent.

I had 9 months' worth.  Then I broke.  At least the code I wrote is
solid - overengineered really.  It'll be there for me when I resume a
year from now.  But man, what a lousy way to handle one's morale.

> But what levels of patience is appropriate for a
> project is pretty much dependant on
> the people working on it, at least in the hobby programming
> area.

I think you have to provide exceedingly quick rewards to developers in
any arena where they're not getting paid.

> Some folks prefer to invest in
> managing multiple future concerns simply because they can
> afford it without running into
> "designers disgust".  They're patient enough.  In such
> environment, it's tough to make them change
> their minds to shift more of their focus on today's fetures
> because their current allocation of
> work on between current and future concerns are working for _them_.

"Masters of DOOM" by David Kushner is illustrative in this regard.  John
Carmack put his developers through *hell* as he was perfecting his
engine.  It was working for John's technological needs, it wasn't
working for other people's game design needs, and it tore the company
apart.

> If one isn't that patience an extreme solution for a hobby
> hacker can be to ignore future concerns
> alltogether in order to speed up short term development.
> That can lead to a horrible product
> implementation which is rewritten over and over again but it
> might on the other hand be written by
> a very amused developer.
>
> For that "pentahexahepta" thing I've lately been considered
> to do the latter.  Take all virtues
> like structured programmed, OO design, security and _LOCK
> THEM IN SOMEWHERE IN A CLOSET AWAY FROM
> ME_.

Yeah, if you *can* succeed in barfing out code in this way, it's a good
idea to do so.  Any working scaffold, however heinous, is better than
sitting around methodically planning without really cutting code.  The
risk of course is when the project does in fact require highly
structural discipline to pull off.  Some neato technologies, you can
just pull out of your ass by shoveling them.  Others, you really do have
to sit down and be an Architect / Disciplinarian.

I think Python is the right language for people who want to barf.  It's
a dynamically typed language, you don't get any more flexible than that!
In contrast, people who do C++ tend to "wax architectural" and get
sucked into optimizing their code.  They end up missing the forest for
the sake of the trees.  It's a disease I've had as a 3D graphics
optimization jock, and I've learned the very $$$$$ hard way to get away
from it.

I can't even fathom people willingly using plain C in 2003 without pay.
That mentality is utterly alien to me, there are far better and more
interesting programming tools available out there for free.  Python is
merely a common one that has nascent market momentum behind it.  I think
library, tools, community support, and proven real world use are all
valuable, so that's why I champion it.

> Just merrily produce that vomit of Perl code.

Yes, Perl is also an appropriate vomit language.  It's just that, I
don't think you can turn Perl into non-vomit afterwards.  But maybe Perl
is a moving target that I'm just not up on.

> Could be an intresting experience.  And likely to be a crime
> against all programming ethics ;-).

There are no ethics, only tradeoffs.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.