Managing "Designers disgust". RE: cheating

[Jakob Ilves <illvilja at yahoo dot com>]

Hello earthlings!

--- "Brandon J. Van Every" <vanevery@indiegamedesign.com> skrev:
> Eric McDonald wrote:
> >
> > No, security should be dealt with when you're doing the things
> > that require security. Perhaps it takes some self-discipline, but
> > that discpline pays off in the long run, rather than a headlong
> > rush to put in new features.
> 
> Eric, I am $60K+ in debt from thinking that way.  Even a volunteer
> hobbyist developer has to have a "business model" of some sort, as to
> how they spend their time.  Lotsa things can be done now "to prevent
> problems later."  But if you are mostly deferring to expected future
> benefits, you will go "bankrupt."   One of the basic laws of Getting
> Things Done [TM] is you have to mostly deal with your present concerns,
> not your future concerns.  There's a budget for future concerns, but it
> has to be kept on a diet, it cannot be allowed to consume you.

Agreed.  On rec.games.design, someone brought up something he called "Designers disgust", the
phenomenom that happens when there is too much work for something in relation to the progress of
the project.  This leads to that the designer finally get's tired on working on the game and also
makes it harder to throw away bad designs, because their implementations were so much work.

(Ok, in this mailinglists context this phenomenom could be called "coders disgust" by those who so
inclined)

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

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_.  Yes, I know these locked in virtues will be screaming to me that "the project is doomed
without us", "it never will run", "nobody will like it" but I'll just ignore them... :-).  Just
merrily produce that vomit of Perl code.

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

/IllvilJa,
on a brief visit on earth.  Very brief though!  Back to orbit!

> 
> 
> Cheers,                     www.indiegamedesign.com
> Brandon Van Every           Seattle, WA
> 
> Taking risk where others will not.
>  

=====
(Jakob Ilves) <illvilja@yahoo.com>
{http://www.geocities.com/illvilja}

Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html