How to Write a Standard (If You Must)

Standards are generally a bad idea. They reduce freedom-of-action and limit choice. But sometimes you must have one in order to pacify an anti-business regulator or other socialist-leaning bureaucrat. So what should you do if you find you find yourself in the awkward position of coming up short in the standards department? By all means, create a standard and do it quickly! I offer here some observations on best-practices, and tried-and-true advice on how to make a standard quickly, with little pain or risk.

First some background. Standards writing, as generally practiced, is a multilateral, deliberative process where multiple points of view are considered and discussed, where consensus is reached and then documented. This must be avoided at all costs. The delays introduced by such a consensus process are considerable and the outcome of such a process does not justify that time investment. If you already have a monopoly, why waste time on a consensus? Consider the notable failures of XHTML, XForms, SVG, XSLT, etc. Look at the multiple implementations of these standards, including viral copyleft and IP-deficient products. Do you really want to see this trend continued?

Start with a complete product implementation. This makes the entire process much faster since there is no time wasted discussing such abstract, heady things as interoperability, reuse, generality, elegance, etc. Only Perpetual Adoration of the One True Implementation (the one you already have) will quickly lead to a specification. Avoid consideration of alternatives. Consideration of alternatives is your prime risk factor for introducing delay.

If possible choose an implementation that has layers of complexity from years of undisciplined agglomeration of features. Of course this will lead to a specification of Byzantine complexity and epic length. But since no one will actually read the specification, there is no harm. In fact the length and complexity can bring several benefits:

1. Any criticism of the specification can automatically be dismissed as nitpicking. For example, if you are presented with a list of 500 faults in a 6,000 pages specification, you can respond, “That is less than 10%. You are just nitpicking. We can fix that in release 1.1”. Or you can even just rely on the familiar justification, “Shipping is a feature”. Any finite list of defects can be made minuscule by a sufficiently large specification.
2. Further, since review periods at ISO and most other standards bodies are of fixed length, regardless of the length of the specification, a sufficiently large specification will ensure that it receives no, or only cursory review. Divide the length of the specification in pages, by the length of the review period in days. A Freshman English major might be assigned reading of 50 pages per day. Aim to double or triple this reading load. 100+ pages/day is a good rule of thumb to ensure that a volunteer on a standards committee will not be able conduct a thorough review.
3. The pure size of the specification will imply to some that it is a well-considered, comprehensive and cohesive document. Just like the IRS tax regulations and the federal budget.
4. In case of emergency the specification can be burned as fuel

Shop around for the best standards development organization (SDO), one that knows how to get the job done quickly. Evaluation criteria include:

1. A proven ability to approve standards quickly. You are not interested in advancing the state of the art here. You want fast-in-fast-out-stamp-my-ticket processing so you can get on with your business.
2. A membership model that effectively exclude individual experts and open source projects from the process.
3. A demonstrated competency in maintaining needed secrecy when developing sensitive standards.
4. The right to make FastTrack submissions to ISO

Ecma International approved the DVD-RAM, DVD-R, DVD+R, DVD-RW and DVD+RW standards. Although some falsely claim that these overlapping standards have confused consumers, it is clear that having these multiple formats has given manufacturers ample opportunity for upselling multi-format DVD players and burners. With a single format, where is the upsell? Ecma clearly understands the purpose of standards and can be relied upon.

Once you are in an SDO and are ready to create your Technical Committee, be sure to carefully consider the topics of membership and charter. Of course, you’ll want to assemble a team of willing partners. Loyalty can be obtained in many ways. Your consigliari may have some ideas.

You charter is your first line of defense. Since your Technical Committee may contain some technical people, you will want to strictly limit what they discuss. Technical people are dangerous if they are given too much freedom. Who knows what they may do if left on their own? They might even innovate (shudder), and innovation is so disruptive. A well-written Charter can prevent innovation, that unwelcome guest, from ever knocking on your door.

Since its terms restricts the scope of your work, you should ensure that your charter contains any restrictions that you do not want to discuss or defend in the future. Best to get these front loaded into the charter so you can just say, “We have no choice; that is our Charter”. Your goal is to describe the One True Implementation, so a good charter restriction to add is one which will focus the technical committee on that one single task. A roundabout way of doing this is to require that the produced specification must remain 100% compatible with a different specification, one which is your secret. That way you, and only you, can decide whether or not a proposed change is within scope of the charter. This provides a lot of flexibility and avoids unnecessary discussions. “We checked the secret specification and it says that October has 40 days in it. Sorry guys, there is really nothing we can do. The Charter won’t let us.”

A few additional recommendations for the the day-to-day work of describing the One True Implementation:

• Observe other successful standards and the process that lead to them. Look at the size of their specifications and how long it took to develop that. Assume that you can safely progress at a rate 10-20x faster. This pace is justified by the superiority of your One True Implementation and your lack of deliberations, discussions or considerations of alternatives.
• At all costs avoid reusing any existing standards. Reuse of standards will only lead to generality, interoperability and increased reuse and risk getting you involved in discussions with other standards bodies. This delay must be avoided. The One True Implementation has everything you or anyone else needs to know. It is the true fons et origo of all wisdom and knowledge.
• This also implies that you do not engage other standards groups. Assume that your hand-picked technical committee is an expert on everything. In any case, expertise is irrelevant, since you are merely describing the One True Implementation. All the decision making essentially already occurred years ago. Your task is just writing it down.
• Secrecy is paramount. If the unwashed masses find out what you are discussing and what issues you face, they might do things like offer you suggestions or alternatives. That is so annoying. So all meetings, minutes, mailing lists, etc., should all be strictly private.

That’s about it. Eveything else is just common sense. Think Speed. Think Heft. Focus on the One True Implementation. I believe the liberal application of the above principles should enable anyone to quickly and painlessly create an International Standard.