The Ambiguity of "Better"
Saturday November 15, 2008
Sean McGrath recently posted an interesting article on software development and, in particular, the writing of specifications. While the thrust of the entry is about the use of specifications for regulation in areas outside of computing (e.g., financial regulation), he brings up a very critical aspect of the software development cycle. "Human language...is a veritable bottomless pit of ambiguity," he writes. This is no more apparent than when comparing a project specification to the software developed against it.
Regardless of which model you are using - RAD, prototyping, spiral, concurrent, etc. - the core stages are the same: status quo, problem definition, technical development, and solution integration. At every stage, however, human interpretation affects the direction taken; ambiguity therefore tends to be the rule. Calling for a "better" implementation or "better" specification writing is not helpful. Specificity needs to be the hallmark. This is a conundrum, however, as any specification written in human language is prone to ambiguity. This leaves us in a tight spot.
Regardless of which model you are using - RAD, prototyping, spiral, concurrent, etc. - the core stages are the same: status quo, problem definition, technical development, and solution integration. At every stage, however, human interpretation affects the direction taken; ambiguity therefore tends to be the rule. Calling for a "better" implementation or "better" specification writing is not helpful. Specificity needs to be the hallmark. This is a conundrum, however, as any specification written in human language is prone to ambiguity. This leaves us in a tight spot.
What do you use to ensure that software is written as close as possible to the intended specification the first time?