[MUD-Dev] Real Life Consequences

[Jon Morrow]

> -----Original Message-----
> From: mud-dev-admin at kanga.nu [mailto:mud-dev-admin at kanga.nu]On Behalf Of
> J C Lawrence
> Sent: Thursday, February 22, 2001 4:41 AM
> To: mud-dev at kanga.nu
> Subject: Re: [MUD-Dev] Real Life Consequences
 
> 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:

Definitely.  Personally, I'm not satisfied with the approach you
listed, but I've no clue on how to improve it.  I'll have to chew on
it for a bit.  :)

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

Great explanation.  Being aware of the different classes though, I
believe a process can be designed to account for them all.  Awareness
of every in and out seems to be the real key.

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

Hmm.  Afraid to follow you down this road.  The philosophical and
psychological sides are a bit too tempting for me.  :)

-Jon

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