December 11, 2006
Unambiguous Specification?I've recently been embroiled in a heated debate about specifications. More specifically, a debate about whether or not it's possible to supply a specification that's so unambiguous that there will never be a need for developers to go back and ask questions of the person who wrote it.
Some people argue that it is indeed possible to create such a specification, given an appropriately formal language to write it in. (e.f., Z, VDM, OCL, SDL etc). If the language is unambiguous, then the specification is unambiguous, right? We can therefore create a complete spec and throw it over the wall to the programmers, safe in the knowledge that all the information they'll ever need to implement it is included in our model. It would seem to make sense, on first inspection.
But after careful reflection, I've come to the conclusion that this is poppycock.
Source code is a formal specification. The code means exactly what it means, and the computer does exactly what the code tells it to do. But I have yet to come across source code that was totally self-explanatory and free of ambiguities as to whether or not the code means what the coder meant it to mean. It may be precise, but that doesn't make it correct. Have you ever read a piece of code and not understood what it was supposed to be doing? Have you ever found what might be a bug and asked yourself "is it supposed to be like this?" Executable code is a formal, "unambiguous" specification, and yet people who use or maintain software applications still feel the need to ask "what will happen when I press this button?"
The only kind of specification that would never require you to go back to the specifier and ask questions is a perfect specification. The odds against such a beast are astronomical, and so I wouldn't bet on finding one on any of my projects.
Try as they might, the waterfall apologists can't argue that a better specification would make iterating unnecessary.
Posted 21 hours, 23 minutes ago on December 11, 2006