[MUD-Dev] Real Life Consequences

[J C Lawrence]

On Wed, 21 Feb 2001 21:51:43 -0500 
Jon Morrow <Jon at Morrow.net> wrote:

>> J C Lawrence:

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

I agree its not ideal, I just haven't seen anything that works
better outside of compleat laissez faire (which brings other
problems due to possible response times etc).

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

> Great explanation.  

Thanks.  I wish all such problems devolved so easily.

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

There are also large questions of ownership and communication.
People tend to occupy camps and to then defend their borders.  That
doesn't work with the above structure, and in fact not only creates
the basic problems, but guarantees their existance.  Its a people
problem, not a technical problem.

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

A few clients ago I had an interesting (to me) discussion with the
Software Director for the company:

  He was looking to select and roll out a new development tool set
  and was concerned that the interface to those new capabilities
  needed to be transparent, intuitive, self documenting, and all the
  other normal HIL stuff.

  I countered that the audience was senior software engineers and
  that they damned well could be both expected to understand the
  tool, and if they didn't like it, to re-write it or put wrappers
  around it, or otherwise mold it to fit their fashion and work
  environments.  I said that due to their being senior software
  engineers, in fact it was best if we didn't attempt to hand them
  compleatly defined pre-canned tool solutions, but instead handed
  them frameworks and internally promiscuous systems that those same
  engineers could then take and adapt and extend and glue together
  as component tools to help them do their jobs in the manner that
  best suited them and was most effective and productive for them.

  The software director demurred on the basis that most of the
  engineers wouldn't do this, that they would complain that it was
  too complex, and that they would not do anything until a compleat
  packaged well integrated solution was handed to them to use in a
  well documented and orthodox manner.

  He didn't like my response that this was an excellant method of
  determining what engineers needed to be immediately fired and
  replaced with actually competant senior software engineers.

I've simplified the arguments above (and made them a bit more
glaring and extreme than they actually were), but the basics are
about right.

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