Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re (tilly) 1: Specify, Specify, Specify

by tilly (Archbishop)
on Oct 02, 2001 at 00:26 UTC ( #115959=note: print w/replies, xml ) Need Help??


in reply to Specify, Specify, Specify

Heresy time.

I do not consider demands for specifications to be always reasonable, nor do I consider strict adherance to them to always be a good idea.

Specifications are often a programmer's way of telling the customer to nail down what they want in detail before the customer can possibly really know. And then when the programmer is done the specifications is a weapon that the programmer can wave around to say that people really did ask for the system they got which doesn't do what they want. And finally since users do not understand the language of specifications, it is guaranteed that they won't produce what a programmer needs to see, and the result is that the programmers get a virtually guaranteed place to start complaining from.

In short demanding a complete formal specification is a seemingly reasonable demand which is doomed to fail in many real-world situations. And users who have been around this path a few times are likely to be wary, they know that programmers (like lawyers) can make weapons of words. If they answer these innocuous questions, they will get what they didn't want and be told that it is what they asked for in the first place. And if it is unreasonable to ask a programmer to make, "Just another small change" with no idea what the implications of that change are, it is likewise unreasonable to ask the user to visualize in vast detail the needs of a system they have never seen, particularly when the demands of the business are likely to have changed in unanticipatable ways by the time it is delivered.

Instead clemburg above indicates a better approach. Yes, the programmer needs some sort of specification. However if you are going to get one, you are going to need someone who understands specifications to sit down with someone who can recognize what a successful system will be, and they need to iterate the design. The specification should be in a combination of media, pencil drawings, example tables laid out in a spreadsheet, use cases, etc. It may need to make it clear where there are grey areas which will be adjusted later one you have a better sense of what is possible and works. It may need to specify some things as being up to the developer, in which case they truly should be. For any complex project it will be incomplete, and this should be formally recognized with contact numbers, and plans for delivery of prototypes from which the spec can be refined.

How much detail is needed will depend on the scope of the project. Clearly a new accounting system will require much more process than a form to email script. However some of the traps to look out for are specifications too incomplete for the programmer to work productively, specifications that the user does not understand, irrelevant and limiting details fixed in the specification which it would be better to leave open, and decisions fixed in stone before people can reasonably know what the answer is. Avoiding these traps often steers you in contradictory directions. But then again, if it was easy, they would't need to pay the big bucks...

Incidentally if someone gives you a spec that you have to make decisions on to implement, either be sure that you have the authority to make those decisions, or else throw the problem back and find something else to work on until you have your answers.

  • Comment on Re (tilly) 1: Specify, Specify, Specify

Replies are listed 'Best First'.
(jptxs)Re: (tilly) 1: Specify, Specify, Specify
by jptxs (Curate) on Oct 02, 2001 at 02:25 UTC
    Couldn't agree more. My $job is to be one of these middle men in the process of making sure everyone is getting what they want. And for sure, whenever the people I work with attempt to bypass me and work directly, in what they call the interest of time, they end up in a mess for sure. You always need someone with one foot in each pond whenever extreme views meet. Layer, interpreter, layer; layer, interpreter, layer...

    We speak the way we breathe. --Fugazi

Re2: (tilly) 1: Specify, Specify, Specify
by pmas (Hermit) on Oct 02, 2001 at 17:50 UTC
    Agree with you that customers might sometimes feel trapped by specifications. Many people can visualise old system, and often you do not just reimplement old system, because there was a reason to do it better.

    I found in these cases useful to write my understanding of what specifications are, and sent them to comment, so users do not need to start with blank page. And is easier for them to comment/criticize if somebody else (me) wrote it.

    Also, after writing "draft specs", I can either continue with another project, or analyze design possibilities of this new one, while ball is on the user's side.

    Yes, specs are important. And as they say, "if something is important and you want it to be done correctly - do it yourself".

    pmas
    To make errors is human. But to make million errors per second, you need a computer.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (5)
As of 2021-01-21 12:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?