Too soon, too late, too narrow, too wide, too shallow, too deep

Abstract

m What makes standards succeed or fail is the subject of much speculation, often during late-night chat. Speculation it always remains: firm conclusions are never reached, or do not bear the scrutiny of cold and sober dawn. Anecdotal evidence is not in short supply, and case studies can be done, but little can be translated into general principle. Standards, it seems, are sensitive plants; one will “take” and thrive, while another, to all appearances equally fit, will struggle to survive at all. ne thing is certain: technical excellence is not sufficient for success. More worryingly, it is demonstrably also not necessary. Some of the anti-standards brigade (and some cynics who claim to be basically pro-standard) even claim that a successful standard cannot be technically excellent, because it is bound to be a compromise between conflicting interests, or because it will be obsolete by the time it gets established, or both. That proposition will not be discussed here, but will be taken instead as a starting point. It is assumed that, as IT professionals, we want to make a standard “succeed,” both technically (to be adequate to the task) and practically (to become accepted and used). We know that many IT standards succeed in one sense or the other, but very few succeed in both. Note that the technical requirement is to be adequate to the task, not to be the best achievable, a point pursued elsewhere [Meek 1995]. Technical and practical objectives don’t always lead in the same direction. We sometimes hear it argued that there’s nothing worse than a bad standard (see e.g., von Sydow [1990])—but sometimes that a bad standard is better than none. Like so much in this area, the answer is not clear cut. It depends on what the aim of the standard is, its context, and the nature of its badness. And even if “adequate” versus “best achievable” is not in itself an issue, what constitutes “adequate” can be, though doubt can be reduced by having clear objectives and conformity rules [Meek 1995]. So, given that we cannot guarantee that a standard will succeed, what can we do to ensure that our standard will be of adequate or better technical quality without putting its chances at risk, so that, should it thrive, it will be seen to be a good standard, rather than “dreadful, but it’s all there is,” or worse? To succeed in practice, our standard will have to meet a need: a need which is perceived; which is regarded as important; and which cannot be met in any other way than by a standard. Many factors will influence this process; many quite outside the control of the standards-makers. Two strong factors are timing and sizing, of which the second has two O Too Soon, Too Late, Too Narrow, Too Wide, Too Shallow, Too Deep