[MUD-Dev] Re: Analysis and specification - the dirty words of mud development?

[Chris Gray]

[Greg Munt:]

 >I decided to give up waiting for someone to add some more to this thread
 >before I responded. I note with interest (and dismay) that the number of
 >posts in this thread are scarce.
 >
 >Is the topic just not interesting enough, do you not feel knowledgable
 >enough to comment, or do you not think analysis has any part to play in a
 >one-person development team? (If the last one is true, you're very, very
 >wrong.*)

I think that depends on our individual goals, and our individual
experiences. Most of the programming I've done, especially in the last
10 years, has been more experimental that developmental. The things we
do at work are likely things that the operating system designers and
authors never thought about anyone doing, so we constantly run into
problems where we are exploring the boundaries of what can be done,
and are way beyond any available documentation. It can be marvelous
fun, and it can be immensely frustrating, but it is clearly quite a
lot different from programming to a predefined spec. Our spec is,
almost literally, "make as much work as you can, however you need to
do it, and it should be as transparent and efficient as possible".

So, when I decided to write a MUD at home (it was meant to be a very
quick hack in the middle of another long-since-abandoned project), the
concept of a detailed plan never occurred to me. It also wouldn't have
been possible, since, even now, my experience at playing or admin-ing
MUDs is virtually nil. Sure, if I was being paid to produce a marketable
product, I would have done a bunch of research first, but that wasn't
the case - I was much more interested in the fun parts of the programming
(I never call it 'coding'), and in seeing how it all worked out.

A smaller MUD server I did (called "ToyMUD" - the sources have been
around publically for a few years) did have some original goals, if you
can consider that a design. It was a fun way to teach myself socket
programming! After that part worked, and I noticed that the whole thing
wasn't very big, my next target was to see how little code it took to
write a fully programmable MUD that maintains an on-disk database (well,
re-writes it on shutdown). (About 3500 lines of ANSI C.) Project done,
and then I wrote the documentation, on how to use it, as well as how to
improve the scenario, and how to work within the server itself.

 >Ok. You are writing for yourself, not for any potential players (a goal of
 >many on this list, I am sure). Since you are developing as a hobby, your
 >time is limited by the amount of spare time that work and the rest of your
 >life leave. Leaping into things may be a lot more fun, but you regret it
 >after the fifth rewrite. (I'm sure we've all been there, at least once - I
 >know I have!)

Er, no, actually. I've rewritten a few hundred lines of a large project
on occasion, but never had the opportunity to rewrite the whole thing.
Hmm. Actually, I think at work I deliberately took time out (a month
or so) to rewrite large chunks, but that was not to change anything
about the way it worked, but simply to clean up the sources, clarify
the partitioning of what parts do what, isolate key header file usage,
reduce the conditional compilation, etc.

Am I unusual in this? Possibly, but then I think my job is somewhat
unusual, and that is how I've gained most of my experience.

So, in short, don't be disappointed if a lot of people haven't dived
into this discussion of design and analysis of MUD systems. My impression
is that a lot of folks on this list have unusual programming experience,
and so what is appropriate to the standard customer-driven programming
shop may not be appropriate for them. That, coupled with the hobbyist
nature of many of us, is an important flavour to this group.

 >* So bite me.

Munch!

--
Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA