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

[Richard Woolcock]

Greg Munt wrote:
> 
> > From: Richard Woolcock <KaVir at dial.pipex.com>
> >
> > 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.)

Note that this was in reference to "end[ing] up with a patchwork quilt of
what you felt like working on that day".  I really don't see it as a problem
for muds - if I get bored of working on my combat system then I'll work on
my character creation system for a while, if I get bored of that maybe I'll
update a few of the old powers to bring them in line with the new code.  I
know what has to be done, I don't see why it should be done in some pre-
determined order.

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

I never said they were used for that.  I do believe that a very important
role is to clarify what the customer wants - customers are well known
for changing their minds about what it is they want, and this can be 
extremely expensive for the developer if they have to fork the bill.

As far as my mud goes, I am the customer as well as the developer.  If
I wrote an analysis it would be for my own clarification, and I already
have a clear picture of what I want the mud to do, with no danger of anyone
claiming I have missed out some features.

> 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

Yes, and an error that the CUSTOMER has made - but if they can prove the
problem is the developers fault, the developer will have to pay for the
upgrades/modifications to be made.

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

I never implied any such thing.

> Bad decisions made earlier in the lifetime of the project are easier to
> fix. Avoid implementing something that the customer cannot/will not use -

No, you implement exactly what the customer asks for.  If you think there is
a better solution then talk to them about it - but you *HAVE TO FOLLOW THE
REQUIREMENTS*.  If you don't then you are not providing the product they
have asked for, and if anything goes wrong...guess what?  You pay for the
problems to be fixed, no matter how good your motives were.

> 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 they are unstated, you get the customer to state them - on paper.

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

And you pay for it.  If you go ahead and do what they want, they will still
say "Ooops, didn't we tell you that?", only this time THEY pay for it.

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

That is correct.  If you also get an independant scrutineer to scrutinise 
your work, then a third person to test it, and a fourth person to scrutinise
the tests, you will have an even greater chance of things working out.  The
question is how far should you take it?

> Back to your question: I assume that you are asking what is wrong with
> writing the documentation after the code.

Nope, I understand the importance of design, but I see little point in
describing a full spec and analysis of how you are going to do it if you
already know.  Obviously it would be an advantage, but I don't think the
advantage would be enough to make up for the extra work involved.  If I
was writing the mud for a paying customer then obviously I would run 
through the full lifecycle, but this is not the case.  I am currently
putting together plans for a new mud, and will be following roughly the
following route:

Specification: In general terms, the theme of the mud, what it has to do.

Design:        List of the code objects which form the backbone of the mud 
               along with descriptions of how they will work.

Coding:        Implementing the mud.

Scrutiny:      The other coder will scrutinise my code and I will scrutinise
               his.  I'll have a codes of practice to follow.

Testing:       A little dry running for complex code, but mainly testing the
               code 'in action' with full logging of functions entered/left.

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

Testing is only required for the finished product - the customer will usually
check before this time to see what sort of progress is being made.  Note also 
that tracability is used to prove to the customer that you have fulfilled every 
single requirement (*rant* and my GOD its boring to do).

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

True, but the customer likes to SEE something, not just a wad of paper.

> The aim is to waste as little time as possible.

The aim is to use the time you have as efficiently as possible, close, but
not quite the same.  If you have 6 months to write some software, there is
no point finishing it in 4.

> Anything produced that is not to the customer's stated and unstated
> requirements is a waste of time, in some way or another.

Agreed, but you should be careful with the 'unstated' part.  Never make
assumptions about what the customer wants.

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

This is true, but I doubt I would do more than scribble a few flexible notes.

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

True, but my problems were more due to badly hacked together code than 
anything.  When I started working on my mud I had never used C before.

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

The requirements/specification are what has to be done, the analysis is how
you are going to do it (see my 'pedantic example', which wasn't intended to
be pedantic - I've had to do the same procedure for code with the wrong
revision number in the header before).

>   Functional Specification - what functionality will the system provide to
> satisfy the requirements? (The system   from the user perspective,
> sometimes called External Design.)

You mean like an object hierachy diagram, or an object design specification?

>   Design - low-level design of the functionality: algorithms, class
> designs, etc. (The system from the developer's   perspective, sometimes
> called Internal Design.)

The low level design, used to develop the code and for independant testing...

>   Coding/Implementation - the fun part

Indeed :)

>   Testing - the, er, not so fun part...

Tell me about it :(  I assume this part includes formal scrutiny?

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

A code of practice?  Definately.

[snip]

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

Quite possibly.

KaVir.