We’re wrapping up the last breakout session of the day at the International World Wide Web Conference in Banff, and someone just asked the panel on "The Future of the Web Page" if Web specifications might be more effective if they were more accessible to non-developers.

The questioner described herself as a product manager with some development experience, but not someone who does development as a primary job: "Without my development background, though," she said, "I think I’d find W3C specifications much less usable. Should those specifications be written with non-developers kept more in mind?"

She makes a good point: a mere specification can open the door to implementations that do conform with that spec today, but do so in a way that doesn’t pave an attractive path toward the future. One of the panelists responded that when developers see a spec that’s encrusted with statements of future intention, "they get very impatient and say, ‘Just tell us what we have to implement.’" So, I guess the meta-question is, "Who’s the real developer?"

There are usability engineers who can tell you what has to be done to make something acceptable to users in practice; there are software architects who can tell you what’s needed to balance usability with performance and feasibility; there are coders who can tell the machine what to do. Clearly, what the coder understands — and is able to find a way to express — is ultimately the only thing that matters. The machine is deaf to "legislative intent."

Attempts to address this issue have been made: if more people were familiar with Don Knuth’s "Literate Programming," even if only as a goal rather than as a basis for building tools, we might see a whole different tone in the process of developing specifications and in the way we write them. In the meantime, paying more attention to specifications is our best insulation against a future of cobbled-together schemes for gluing together the proprietary innovations that succeed.