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

[J C Lawrence]

On Tue, 9 Jun 1998 18:17:34 +0100 
Greg Munt<greg at uni-corn.demon.co.uk> wrote:

> I've been on this list for over a year.  Throughout that period, the
> list's discussions have been biased towards design. The logical
> conclusion of this, is that one or more of the following is true:

That pie-in-the-sky design is considered "interesting" or at least
"provocative" and the other more mundane aspects of software
development, well, mundane.

> 	List members (read: mud developers) find analysis and
> requirements specification so easy that they do not feel discussion
> of related issues is warranted, or indeed relevant.

The early days of the list had a lot of this sort of content, heavily
championed by yours truly.  Mostly this revolved about my requirements
for being able to implement game features with limited source access
which spawned several very long (multi-month) threads which in turn
spawned such as the Castle Krak, Elven Forest and Sceptre scenario,
the Daemon Wroth scenario, the Crystalline Tree scenario, and various
others.

Since then the list in many ways has become much more light weight.
Mostly it has become a lot less technical (which I rather regret in
many ways, much tho I value the other aspects in which the list has
grown).  Many of the current threads are extremely high level.  

How long has it been since we've had a thread on the list actually
discuss the __implemenation__ of an idea, or even its nitty gritty
details?  This used to be common.  I wish it were still.  It is the
sort of discussion that is utterly lacking on Usenet (not a chance of
it there), and which the field desperately needs and suffers for the
lack of.  

We have the resources in the membership of the list to make a fearsome
gauntlet for any idea.  If it can get thru us, or even if it can't but
its champion still feels its valid after evaluating the gauntlet's
review, you've got something there.  Perhaps the gauntlet of devil's
advocates has proven itself so fearsome that nobody dares to run it
any more?  (Several have alluded to this last possibility) Orn I
recall decrying what he saw as the adversarial and excessively
free-form nature of much of the debate of his time.

All that said, I suspect a common reason is that much of the
discussion of requirements and the like is considered so specific and
particular to a particular system or server attempt that it is either
not worty or thought of as noise to the rest of the list.  

This latter is a shame.

> 	List members do not carry out any requirements analysis, or
> none of merit/worthy of discussion.

I suspect that the majority are entirely informal.  Mine are.  I use
statements of broad policy, and then logs of notes and concepts of
where I want to head.  Almost all the rest rests in the cranium.  

I use formal design for the overlaying pattern, the broad sweeps and
brushstrokes of data flow, control, and structure.  The little bits I
wing and rely on source to diagram.

> 	List members are not interested in discussing these stages of
> development.

Most outside the professional realms, and especially outside of Govt
and other highly structured ends of the programming profession never
need touch formal design specs for a project and so never think in
those terms.

"Bloody paperwork" is a phrase I hear often, even in the OS vendor
camps.

> Many (I'd say 'all', but I can't allow myself to be that
> pessimistic) mud developers that I know are not that at all, but,
> instead, are mud implementors. Design is little more than an
> afterthought, so hopes of any analysis being done are comedic, at
> best.

Nahh.  There are many levels and viewpoints on design.  Some, not all
are expressed on list.  Others are implied but unstated.

> As a firm believer in the neccessity for QA procedures in *any*
> software development, I am keen to discuss these previously
> untouched areas of requirements analysis. 

Such as?  I've spent a fair amount of time working in the QA labs of
the world.  That said, QA is a field full of needless complexities,
self-contradictory methodologies, limited application approaches,
etc.  Its not a trivial game, and there are no global patterns that
scale worth a Cockney bloody damn.

<<eg I'm a big fan of assertion based testing and of statistical
testing, which complement each other rather well.  Just try and apply
assertion based testing to a complex system like a word processor...>>

> My early forays into them are self-condemned as too low-level, and
> having no commercial experience, I'd be interested in how others
> have progressed with it (particularly on commercial projects).

Yes?

> My requirements thus far seem to be based around the tools which
> users will use to satisfy their requirements, rather than specifying
> the requirements themselves. The fact that there is no physical
> 'customer' is not helpful, either.

I tend to base requirements on functional definitions and functional
resource requirements (to do X you must not need more than Y).

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...