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.