Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: Benefits of the Specification

by Malkavian (Friar)
on Mar 08, 2001 at 16:30 UTC ( #62952=note: print w/ replies, xml ) Need Help??


in reply to Benefits of the Specification

A good spec is a joy and a necessity for getting a large scale project right.
A fair part of the time of engineering a project should be spent on the spec, getting queries from both sides sorted out. Once it's been done to death, and both sides agree it's a feasible and accurate document, comes the initial design.
After finishing something that seems to represent exactly what was in the document (a real spec shouldn't be wooly, so the design should be an accurate representation), you go to prototype.
Prototyping is just a quick hack of the design in a rapid development language. This is what is demoed, and the originator of the spec should be able to say "Yes, this is exactly it" or point out in the spec what has been misinterpreted.
However, at this point, a 'customer' should not be turning round and saying "Oh, we just thought it'd be really neat if this supported this whole new basic philosophy!".
If they do, an appropriate response would be "Yep, it'd be really great if it did, but it doesn't.".

An analogy:
Man goes to car showroom and says "I'd like that model of car, in red, with heated windows and low profile tyres please. I'll order now.".
Dealer then promptly orders car which turns up.
Man then turns to dealer and says "But it doesn't have tank tracks on it for doing serious offroad! It'd be really great if you could just put them on for me now at no extra cost.."

In short, they've asked for something. They've been given proof that their product is there, and they've got what they asked for.
Once the spec is done and dusted, it's a contract. Allowing one side of an agreement to go changing it and not the other is rather unfair (how would the customer feel if the developers turned round and said "Hey, neat idea to really make this thing run fast! We're removing the user interface for performance optimisation"..

However, sometimes, changes aren't that bad. These days, there are CASE tools for development (see a few case tools here).
If the request comes in early enough, changes may be made to sections of the model, and the code base regenerated from the design. In most cases, only sections will require redesign, and as long as all internal interfaces are not altered, the majority of coding is still valid.
My personal opinion is that the Spec document is the most important part of the process. If that's wrong, then everything else will follow.
Once it's done, it's done.
If someone starts saying "We want this feature", they really should be hearing the reply "Well, when the next version is released...."
An example of bad use of spec was in my time working for a very large UK Telecoms company as a contractor.
In one short meeting, I was requested to provide an access mechanism to a remote tool, and allow logs to be accessed from it an analysed. In almost those exact words.
When asked if I could have a real spec document, people went quiet, said they didn't have the time, and that it was a 'waste of resources' to do that. Which irritated me no end.
Then I was asked how long it would take to do. Given it wouldn't take long to write the code to access the tool in question, tie it to a database, and check it worked, I gave time as about 3 weeks including rough testing.
Everyone agreed to this, and off I went.
Almost as soon as we left the meeting, people started coming up and saying "Oh, and it needs to do this too."..
Needless to say, the original deadline wasn't allowed to be moved, as I'd said it would take three weeks to build. But the company was allowed to shift the goal posts.
The first version was released 2 weeks late, due to extra features included.
When it was first displayed, people from disparate departments who didn't even turn up to any of the meetings started saying "But how are we supposed to put people who are remote to the client you've written, with no tech training and no time to learn how to access a command line command supposed to use it? We need this! It can't be used without this!".
So, back to the drawing board. The rework was from the ground up, and what was now being coded looked nothing like the original request. The scope of the project was way out of wack, and the timescales too.
The saddest part of this is that even after I'd explained to them (after completing the project) that the whole thing could have been done far faster and more efficiently if a Spec doc had been produced, next project to come round, they did exactly the same thing again.
Needless to say, I left in disgust, and stress, and am now at a place that understands the need for doing things properly.
A spec doc is rarely right "First time", which is why you need several people working on it, to bounce ideas around, and pick out holes. That way, you know what the product IS before you ever start the formal design methods.

If you don't know at this point what it looks like, you may just end up asking for tank tracks later..

Just my tuppence worth,

Malk.


Comment on Re: Benefits of the Specification
Re: Re: Benefits of the Specification
by lachoy (Parson) on Mar 08, 2001 at 23:29 UTC

    Specifications are good, yes. But I disagree that they can (or should) never be changed. Customers typically don't know everything developers or technology can accomplish that they can exactly describe what they want, and developers rarely know enough of a customer's business process to explain how the final product will look and act. (There is plenty of ego on both sides that screw things up: customers think they know what the best technology to use is and developers think they can re-engineer a customer's business process.)

    Both are (IMO) best served by a process marked by short iteration periods and involvement by all parties (customers, developers and mangers) at all stages. As tilly pointed out this is one of the fundamental tenets of XP. I'm only about halfway through the recent book Planning Extreme Programming, but it's done a good job so far of pointing out trouble areas and describing the discipline necessary on everyone's part to make an iterative process work.

    The projects I've been involved with where we tried to figure out everything necessary for the entire project at the beginning never did well because nobody (including me) appreciated the power of change.

    Chris

    M-x auto-bs-mode

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://62952]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (5)
As of 2014-11-29 05:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (203 votes), past polls