Specs, waterfalls, terminal completeness

I’m working on a project in which some of the deliverables are specifications. I haven’t written many documents that would properly be termed ‘specs’ before, so I’m learning a good deal from the experience.

One thing I was just pondering is that if one works for the goal of making a ‘complete’ spec, one is assuming a waterfall model of development (Wikipedia: Waterfall model, Why people still believe in the waterfall model), which is bad. In real life, a spec is a sort of snapshot of a continuing process, which is therefore not ‘complete’ (unless your philosophical orientation says that a thing is always complete in itself by its own definition).

This does remind me, though, of one of the complaints one often sees about consultants. One way to relieve the tension between completeness and a continuous process is to construct a shiny veneer of completeness, then take the money and run before the process comes back around to show the holes in the veneer.

Of course, it’s necessary to choose some point at which to exchange artifacts for money and call it “done enough for now”, so maybe it’s all in the attitude.

2 Comments

  • 2006/04/08 - 00:00 | Permalink

    In my world, I tend to write the program, get everything working just right, and then some QA guy says that there needs to be a spec, according to some other qaulity spec (QXYZ 123498). So then we write the spec, based on how the actual program works, rather than the other way around.

    Wonder if there is a name for that development method.?

  • Steven
    2006/04/08 - 00:34 | Permalink

    Good question; I’ll have to look that up. ‘cuz I actually think that method is more defensible, practically speaking, than many others.

    I suppose XP (http://www.extremeprogramming.org/) and similar methods can be likened to that approach. Then there’s the school that says that the running code _is_ the specification; I can agree with that position to a degree too.

  • Leave a Reply

    Your email address will not be published. Required fields are marked *