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

[Richard Woolcock]

Mike Sellers wrote:
> 
> At 06:46 PM 6/10/98 -0700, Richard Woolcock wrote:
> >Greg Munt wrote:
> >[snip]
> >
> >> 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.
> >> ...
> >
> >The importance of specifications and analysis lies in being able to turn
> >around to the customer and say "well, you didn't ask for *that*... but for
> >extra $$$ and a deadline slip we could do it for you".  Believe me - some
> >companies depend on this happening to be able to get their software completed
> >within what are - initially - impossible deadlines.
> >
> >As far as a mud goes... The implementor/coder decides what s/he wants in the
> >mud and work to that.  They don't have to explain to other people exactly
> >what the mud is going to be like, because they are the company AND the
> >customer all rolled into one.
> 
> I couldn't disagree more.  The importance of analysis and design has much
> more to do with managing architectural complexity, robustness, and
> extensibility than it does with cloaking impending schedule slips.
> Formalizing this process is *critical* on a multi-person team, but even on
> a single-person team, you need to have _some_ level of overriding design so
> that you don't end up with a patchwork quilt of what you felt like working
> on that day.

Does it matter what and when you work on things, as long as they get done?

> Designing things in advance lets you see the long view and
> then drill down when you need to without worrying that what you implement
> today is going to give you a headache tomorrow.
>
> In general, the better your analysis (what do we need?) and design (how do
> we put it together?) work before you begin coding, the faster your

Hmmm well I generally use the terms as:

   Specification: What has to be done.
   Analysis:      How you are going to do it.

I use 'design' as a term referring to the actual high/low level designs,
including any DFDs/etc.  I believe that the design plays an important role,
while the analysis isn't so important for a mud if you are the sole coder.
I know what I want to do, I know how I am going to do it.  What I need is a
consistant design to stop me deviating from that goal.

> implementation time will be, the fewer bugs you'll have (especially really
> deep, nasty, architectural bugs), and the more things you'll be able to add
> later on when you think of them, without having to go retrofit everything
> with global variables, spit, and chewing gum.  Not to mention that a strong
> analysis and design makes it *much* more likely that the end product is
> going to be much more usable if the users' needs were taken into
> consideration from the start, as part of the overall analysis.

I think the main difference is that you consider the players to be the 
customer, while I consider myself to be the customer (of my mud).  If
the players were customers then yes, I would agree with you totally.

> Of course, the analysis and design phase has a bad rap because it _feels_
> like you're not getting anything done.  It's sort of a tortoise and hare

[snip rest of explaination]

Specification of problem:
   The mud cannot accept more than 100 players at one time.

Analysis of problem:
   Within the following header file:
      Socket.h
   The following literal:
      #define MAX_PLAYERS 100
   Shall be modified to the following:
      #define MAX_PLAYERS 200
   This shall allow upto 200 players to be connected at one time.  The
   object design specification shall also be updated to reflect this change.

Requirements tracability impact:
   Within the following section:
      1.1.3 Player limitations
   The number '100' shall be replaced with the number '200'.  The tracability
   matrix shall be updated to reflect this change.

Verification method:
   Changes to the high level design shall be verified by scrutiny against the
   requirements document, the design document, the codes of practice for
   verification and the tracability matrix.
   Changes to the code shall be verified by scrutiny against the module
   specification, the requirements document, the design document,  the codes 
   of practice for C coding and by independant module testing of the affected
   item.

Maybe we are getting our wires crossed...could you give a brief example of
what you consider 'analysis', 'specification' and 'design'?

> >IMO a far more important phase in mud development is the scrutiny/testing
> >phase, which is also very much lacking.  Why?  Because its boring as hell
> >and no fun to do, and if its no fun the mud stops becoming a hobby.
> 
> Testing is a lot less onerous if you've done solid design work in advance.
> :-)

True, but I have never doubted the importance of design.

KaVir.