[MUD-Dev] Real Life Consequences

[J C Lawrence]

On Tue, 20 Feb 2001 21:25:09 -0500 
Jon Morrow <Jon at Morrow.net> wrote:

> Ethically challenged players or ethically challenged developers?

The boundary conditions htere are hairy, subjective, and ripe for
abuse and manipulation -- as witnessed by their being a favourite
target of grief players.  The most successful approach seems to be:

  If you think it might be a bug, don't do it.  We'd appreciate it
  if you'd tell us about it as well, and we may in fact reward you
  for doing so.  

  If we told you it was a bug, don't do it.

  If you continue to do it, we'll warn you once.  Anything past
  that once may be considered an accidental oversight, and is not to
  be relied on, and is most specifically not a statement of policy
  or practice.  Yes, this is a warning.

  Don't argue with the warning, and don't continue doing what you
  were doing.  If you have questions, don't bug the admins, just
  take the course most likely to not have an admin assume you were
  deliberately or willfully abusing the bug.

  A notice will be posted when the bug is addressed.  It is up to
  you to look for that notice, and to refrain from that bug until
  you see an explicit notice (ie doin't go testing it to see if its
  still there -- that likely will be viewed uncharitably and assumed
  to be deliberate exploitation).

  In all your interactions with the game admins, remember that while
  you are an individual, and thus have individual concerns and
  questions, the admins have hundreds if not thousands of players to
  handle and they appreciate your cooperation in making that task
  easy -- which also acts as an explanation, if not justification,
  for the typical vehemence of their reaction when it may seem that
  you are wilfully making their task more difficult.

>> Ultimately, the developers do not suffer from bug-exploitation,
>> but rather, the other players do.

> Oh?  I think both suffer.  If one of my developers constantly
> produces buggy code, fails to fix it, and allows bugs to be
> exploited rampantly, I will not hesitate in firing him/her.  And
> being without a job is generally considered suffering.  Of course,
> the game might not have decent management.  In this case, bug
> exploits would probably destroy game balance, it would become less
> attractive to players, and their revenues would drop.  Suffering,
> once again.

Loosely there are three classes of bugs:

  Flaws in the implementation of a feature as compared to the
  design for that feature.

  Flaws in the design of an implementation of a feature as compared
  to the larger design.

  Flaws in the larger design (these are often at the level of
  incosistancies, oversights, and unhandled implications).

These three are of course a sympathetic and tightly related system.

All three problems are common.  Typically in larger projects
different people are responsible for each level, and equally
typically, the larger design guy doesn't know the implementation
design, and visa versa, leading to disconnection and
communication/translation/execution problems.  It can be easy to
blame systemic problems on the individuals who aren't responsible
for them.

>> Apart from all the above cynicism, I like the idea of smaller,
>> user-controlled servers vs. large nanny-state servers.  But I
>> don't think "eliminate all the bugs prior to release" is a
>> realistic solution to the problem of bug-exploiters.

>> You *can't* eliminate all the bugs, and if you have thousands
>> upon thousands of users then you'll have one cubic crapload of
>> bug-exploiters regardless.

> I'm glad we have some common ground.  Eliminating "all the bugs"
> is close to impossible.  I believe, we do, however, have room to
> improve our development processes.  I also think the impact would
> be significant.

The biggest problem I see is that the base ideas of what builds
quality systems is not understood.  Its partly a question of
process, but it seems more a question of understanding that process
at an intuitive and implicit gut-level in terms of "that is what my
job is and who I am".  Few people like testing their code or runnng
about fixing all the second and N'th order implications from their
last design change.  It gets a bit better when they start thinking
that, "real programmers/designers/whatever" (in which class they
think of themselves) of course do that, and would not be caught dead
not doing that.

It needs to be at the same level as why they bathe regularly.

Expectations.  A sense of repect and definition of self and one's
work.

--
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev