Spolsky (and Usdin and Piez) on specs

Joel Spolsky (of Joel on Software) has put up a talk he gave at the Yale Computer Science department a few weeks ago. (Actually, he put it up a few weeks ago, too, shortly after giving the talk. I’m just slow seeing it.)

In it, he has an interesting riff on specifications and their discontents, which feels relevant to the perennial topics of improving the quality of W3C (and other) specs, and of the possible uses of formalization in that endeavor.

If the spec defines precisely what a program will do, with enough detail that it can be used to generate the program itself, this just begs the question: how do you write the spec? Such a complete spec is just as hard to write as the underlying computer program, because just as many details have to be answered by spec writer as the programmer.

This is not the whole story, by any means, if only because specs can and often do explicitly refrain from specifying everything a conforming implementation is to do. But it raises an important point, which is that the more precise one tries to make a spec, the easier it can be for contradictions or other problems to creep into it. (In my experience, this is particularly likely to wreak havoc with later attempts to correct errata.)

In their XML 2007 talk on “Separating mapping from coding in transformation tasks”, Tommie Usdin and Wendell Piez talk about the utility of separating the specification of an XML-to-XML transform (“mapping”) from its implementation (“coding”), and provide a lapidary argument against one common way of trying to make a specification more precise: “Code-like prose is hard to read.” (Has there ever been a more concise diagnosis of many reader’s problems with the XML Schema spec? I am torn between the pleasure of insight and the feeling that my knuckles have just been rapped, really hard. [Deep breath.] Thank you, ma’am, may I have another?)

How do we make specs precise and complete without making them as hard to write, and as hard to read, and as likely to contain insidious bugs, as the source code for a reference implementation?