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

[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.*)

----------
> From: Richard Woolcock <KaVir at dial.pipex.com>
> 
> Mike Sellers wrote:
> > 
> > At 06:46 PM 6/10/98 -0700, Richard Woolcock wrote:
> > >
> > >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?

Yes, yes, yes, yes and yes. (Ok, it was only one question, but I really
needed to add some emphasis there.)

Do you really think that analysis would be part of well-established
software development process models (firmly backed by the academic
community) if they were used simply to obscure slipping schedules?

If something that the customer wants is not included in the requirements
spec, and later, in the analysis, then that is a mistake, a flaw in the
communication with the customer, an error. It is a bug at the analysis
stage. Your statement implies that software development companies aim to
misinterpret customer requirements, in order to justify more time - and, by
implication, more expenditure. That's bollocks.

Bad decisions made earlier in the lifetime of the project are easier to
fix. Avoid implementing something that the customer cannot/will not use -
document what they want at an early stage. Remember, the important thing is
not to get something - anything - running as soon as you can, but something
that is well-designed, something that *works*, and _above_all_ satisfies
the user's requirements (some of which may initially be unstated).

If you go ahead and do your own thing, then the customer says, "Oops,
didn't we tell you that?", you have to redesign, reimplement and retest.

If you specify properly, and document everything that you think that the
customer has asked for, they can verify it, and tell you about errors then,
instead of when you are into the implementation stage. (Note that there are
no guarantees to this approach, you only have a greater chance of things
working out!)

Back to your question: I assume that you are asking what is wrong with
writing the documentation after the code. One way of looking at it is that
x hours have been spent designing, coding and testing (only then can the
customer verify that you have developed what they have asked for - or meant
to ask for). OTOH, if you have spent y (which is *significantly* less than
x) hours specifying and documenting, and show your documents to the
customer, they can tell you what is wrong then, instead of when (let's be
honest) it's too late. The aim is to waste as little time as possible.
Anything produced that is not to the customer's stated and unstated
requirements is a waste of time, in some way or another.

>    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.

Hmm. Are you sure you know what you want to do? Isn't it better to start
the development of a system at the highest level that you can, instead of
getting into the nitty-gritty from day one?

If you do analysis in your head, the chances of missing your mistakes soar.
 
> 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.

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!)

> Specification of problem:
>    The mud cannot accept more than 100 players at one time.
>
> [Rest of pedantic example snipped]
>
> Maybe we are getting our wires crossed...could you give a brief example
of
> what you consider 'analysis', 'specification' and 'design'?

You shouldn't approach things as problems. At worst, they are system
constraints imposed upon you. These constraints may be dictated by customer
requirements, or by hardware (as in this case), but they can't really be
defined as problems, I don't think.

Steps in my development life-cycle (and it *must* be a cycle!):

  Requirements Specification - what customer requirements need to be
satisfied by the system?
  
  Analysis - unsure about this, and that was the reason for my original
post. The bridge between requirements   and functional specifications. I
guess it specifies why and how a particular part of the functionality will
satisfy a   particular requirement. (Any input from you lot on this one?)
  
  Functional Specification - what functionality will the system provide to
satisfy the requirements? (The system   from the user perspective,
sometimes called External Design.)
  
  Design - low-level design of the functionality: algorithms, class
designs, etc. (The system from the developer's   perspective, sometimes
called Internal Design.)
  
  Coding/Implementation - the fun part
  
  Testing - the, er, not so fun part...

The higher up in the list, the higher level that the document is. I'd
recommend documenting your procedures and standards too - even if you are
the only person involved in development.

> > >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.

I think his definition of design encompasses design and all previous stages
- whereas yours does not.

Greg.

* So bite me.