[MUD-Dev] Re: MUD-Dev's DevMUD: a word of caution

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

Cynbe ru Taren wrote:
> Not to play the heretic,

Why not?

> but does anyone want to list their favorite
> 10 software success stories and count how many of them followed this
> methodology?  :)  

> Emacs?

Success for the same reason PERL is a success, but success is not really a
well defined term when it comes to software, is it?  I mean, Microsoft,
early Windows...

>  Gcc?  Linux?

Not innovative. (so shoot me) Well known territory.

> MOO?

Success because somebody got raped?  Maybe not... dunno.  Is it a success? 
I've never thought of it as a success. I am sure many do though.


Most of these were probably a success because they were free, there was
little competition when they got started, they got publicity and were fairly
stable.  Today there is plenty of competition, so you actually have to do a
lot better than those systems did in their initial design... DevMUD won't be
able to recover if it starts out like Linux. MUD developers are not that
hungry.

I have no knowledge about the process behind well known software but I think
these must have followed a fairly conscious path:

  Postscript
  Unix
  Photoshop
  Lotus Notes

I know that several business applications and a wide variety of systems
tailored to organizations has followed structured paths with success (some
evolution is necessary though)...  That's where the formal methods come from
(not to say that applying a method results in a success, a method only works
within a limited domain)!

Evolution is of course good, but I'm not sure if it is a good idea to design
for massive (lacking a better word) abortion! You hafta survive the birth,
then you have to make sure it is a good starting point for evolution... 
Anyway, a good technique is to interview the potential users. Mud-dev is
fortunate in that respect, the list can interview itself.  Albeit, the
DevMUD people hasn't really taken the information collecting task
seriously...  Thus there can never be a list of requirements, unless you
want fiction...  Fiction can be good, but perhaps there are better ways to
build the typesetting machinery?
 
> Mebbe people willing to do this should speak up.  If the count is
> zero, I expect everyone can save their breath.

                             8-x

> I'd cite the IETF at its best as an example of the above process:
> members develop the drafts offline, then the group tears into it
> in a review.   Iterate to fixpoint.   No?

This assumes that the field is well known, that the outcome is somewhat
predictable.  When it comes to MUDs I think the problem is more in finding
the real needs and the really good ideas, rather than choosing the right
path and decision making...  DevMUD was supposed to become an option for
commercial muds, right??  Well, that probably defines some requirements... I
really don't think dynamically loadable object code is critical enough to be
the main focus, might be useful on the client side though. Fix one bug, get
four new ones? In a commercial setting I think one would prefer to let the
QA team put the machinery through hell for several days before updating
servers with paying players on them. Thus the object code update frequency
should not be high anyway.  If for no other reason, it costs money.
--
Ola