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

[Greg Munt]

I have not followed discussions too closely, so forgive me if I'm
repeating what has been discussed before. (If it has been, it would seem
to have been ignored, so I can still claim some validity for this post..)

Firstly, I am somewhat concerned about the impact that the DevMUD (only a
programmer could have thought that name up, but that's by the by - and
yes, I do consider myself to be a programmer) thread has had on this list.
We are in danger of MUD-Dev becoming a mailing list for the development of
a single mud project. That's sort of bad, really - and quite definitely
not what this list was set up to achieve. 

Secondly, I am disturbed by what is being discussed. Already we have 
decided on the implementation language (people are even posting code!), 
and on various really low-level technical/implementation issues.

Admittedly, I have not paid too much attention to the thread (to be 
honest, it's NOT the sort of thread that I subscribe for), but I have not 
seen any discussion of the purposes of developing this software, of what 
requirements it is being designed to meet, of ANY high-level design at all!
If the project is to move forward into something more than the discussion 
of ideas, (I actually have reservations about whether that is actually a 
good idea - these are described below), it needs to have a concrete 
foundation. A foundation which minimally consists of a full requirements 
analysis, and full documentation of EVERY facet of the software, and of 
every decision made and why it was made.

This project is in danger of becoming nothing more than some hacked-up
piece of junk that is the exclusive property of the more code-oriented
list members. I have seen little or no input from the designers on this 
list - and that must change if the project is to become more than a pipe 
dream. Think to yourselves: why do I want to do this? When it's finished, 
what will it be used for? Will people want to use it? Why? It's all well 
and good to say you are doing it for the fun and enjoyment of doing it - 
but it won't result in anything worthwhile unless you have some strict 
rules in place. The importance of analysis, design and documentation is 
so high that it cannot be measured - particularly in a team effort, and 
particularly when the team is potentially large. The way that things are 
going, these important elements are going to be ignored, because those 
involved just do not want to do those things. Many contributors to the 
thread seem more interested in how it will be implemented than whether it 
will be usable, whether it will satisfy the needs of anyone outside those 
developing it, and whether anyone else will be able to work out what the 
hell is going on.

Simply: if you want to develop a mud for your own pure selfish pleasure 
(most of us are doing that, and it is probably the main reason for most 
of us subscribing to this list), develop your own mud. This so-called 
DevMUD project needs to be handled in a more professional (some would say 
boring, I'm sure) manner - at least initially. When you have the firm 
foundations, then you can start thinking about cool things to put in, and 
maybe relax the rules a little.

But until then, think about what you are doing a little bit. The 
consideration of social issues (relevant to ALL muds, since ALL muds 
cause the development of a community) needs to be an integral part of this 
thinking.




Ok, here's the next part of a post that will probably be mostly ignored 
(and this is a part that will almost definitely be ignored most of 
all!).. I want us to think about what will happen to the product of all 
this development (hard, because we have done no requirements analysis, 
and certainly no documentation of it). From what I have read in the 
thread, it appears that the project will produce modules for other mud 
developers to use in their own endeavours. While a noble goal, I feel it 
is a rather naive one.

Looking at the history of the free mudding field, we see a flagrant 
disrespect for the intentions of the original developers of a mud branch 
(cf Keegan's Tree). Mud developers release code to the Internet in the 
hope that it will help and assist further development of new muds, and 
indirectly, the field itself. As we all know, in the majority of cases, 
this just does not happen. (Yes, we are coming to my pet topic.) Let's 
use an easy example. Let's look at DIKU. In its day, I'm sure it was 
good. But its reputation today is very poor - having been sullied by the 
ignorant. I assume I do not need to explain further here?




As an endnote: I've been given unpaid leave to go to the Bahamas (where my
fiancee lives) to see if I have any chance of finding employment there.
I'll be married with children before you know it.. (Hmm, is that good? :-o)