Most of the people reading this may never be in charge of writing standards and thus be inclined to skip this post. Don't. These rules may be for the writer, but it's up to the user to ensure they are followed. If a standard is breaking a lot of these rules it's up to the people who adopt standards to choose NOT to adopt it. Remember IBM and Sun and Microsoft may be big, but the people writing code are a lot bigger and more powerful. Maintaining intellectual integrity is the best way to keep the worst instincts of the big guys in check. In short we need not use the processed bovine nutrient they dump out just because they dump it out. So, wielding the staff of Fiat granted me by my fathers of old I hereby and henceforth declare the following five rules for software standards.

The rule of size

"Any standard that cannot be written by three people over a period of three nights with suitable caffeinated beverage support should not be a standard. There is no limit on how long it takes to figure it out, only on how long and complex its expression is."

Basically big standards suck and are useless. When people start making a standard bigger they are trying to solve more and more problems which is another way of saying that they do not clearly KNOW which problem they are trying to solve. Are there big problems out there? Yes, but it is very unlikely that trying to solve them all at once via standardization is the right answer. When a problem is really big it is probably many problems that all have something in common. Rather than spending time writing an "ultimate" standard it would be better to spend time figuring out what some of the core problems that make up the big problem are so that they can be solved one at a time.

Another reason that small is better in standards is that it deters striving for perfection. Humility is a critical aspect in building good standards. This is because standards are a form of design and trying to get everything perfect in a design before you write the code is a fruitless effort. In a standard it is suicidal because unlike a regular design which people can simply ignore, people will be FORCED to adhere to the standard. So in standards creation it's better to keep them simple and open-ended and to humbly acknowledge that we don't know what we don't know. This is YAGNI for standards.

The rule of growth

"When updating standards the total size of the standard cannot change by more than 5% per year."

We should avoid arbitrarily extending standards; this is virtually a corollary to the first rule and the same reasoning applies. Most standards could use a revision or two, but the goal should generally be clarification and not extension. It's also good to remove things that have proved confusing or that are unused (although for some reason no one ever does this). Backwards compatibility need not be a feature of a standard, standard implementors can continue to support the old features if needed even if it has been removed from the standard.

If there are good ideas that the standards need then I recommend new standards; these can be extension standards rather than extensions of the standard. The problem is that standards that are popular are powerful and as such powerful interests are inclined to manipulate them. Whatever the new version contains will have to be supported so extending standards provides opportunities for abuse.  If you assume the new version of the standard will be valuable and correctly done then extending it seems good since it will keep things moving forwad.  Unfortunately, even if we assume people writing standards do so with the most altruistic and pure motives, standards are like untested code; until they've been in place for a while it's a bit hard to know if they are good or not.

Extension standards (unlike extensions TO standards) need to earn their place in the market and taking those efforts out of the initial standards effort provides small and large companies opportunities to disagree and propose competing alternatives. In short it takes the power away from a small group of potentially powerful interest groups and places it back in the hands of the standard users (coders).

The rule of consensus

"Excessive consensus building is to be discouraged.  If two or more people (or organizations) discussing a standard are in strong disagreement let them go their own ways and write different competing standards."

This rule flows from my observation that some of the worst standards ever written are those that are the results of consensus building between standards bodies with competing perspectives. Consensus frequently means everyone agreeing to do what is wrong so they can smugly proclaim that the resulting failure was due to the other guy's bad ideas. A standard should have a relatively clean and simple vision if it does not then it will fail.

People look at HD-DVD and Blu-Ray and say, "see how expensive it is to have competing standards, we need to always look for consensus so people don't waste time and money." This may be true for hardware but it is much less true for software. The percentage of hardware standards that prove workable is extremely high, the percentage of software standards that hold up over time is extremely low. In an environment where failure is a high probability event a diversity of options is an extremely sensible alternative to putting all one's eggs in one basket.

A lot of the time I hear people grousing about how the fact that people aren't adopting standard X or Y is a horrible thing and how the world would be a better place if people would just do things the "right" way. To me this is verbal shorthand for "I'm right and if you all just get in line my life will be easier." I've felt similarly and expressed this opinion from time to time as well, but my perspective is just a little more egalitarian. Sure I think JSON is better than XML and I'll tell you why, but at the end of the day it's your call if you want to go with XML for everything from properties files to language extensions to communications. I'll even talk to your system with it if I need to. Just don't be surprised if I also choose NOT to use your great XML alternative if I think it's a pain in the hind-section.

The rule of frameworks

"Frameworks may not be standards. Ever."

This rule is harder to define clearly, but in essence it is an argument against horizontally intertwined standards AND an argument that no standard should ever position itself as the owner of your program space. Consider the IP to TCP to HTTP chain as an example of a properly related set of standards. It's very possible to use TCP without explicit and detailed knowledge of IP but you couldn't write TCP without that knowledge. Similarly you can use HTTP without too much knowledge of TCP and with virtually no understanding of IP at all and this is all good. This is a nice vertical stack.

A standard becomes a framework standard when it takes four or five standards that should (or perhaps do) stand on their own and puts them together in such a way that you need to UNDERSTAND all of them in order to use the standard.. So if, for example, you need to understand JNDI in order to obtain a database connection from JTA there is a problem. If JTA simply used JNDI without requiring your intervention, use, or understanding then it would be better. If instead it could work with any number of alternative services without your knowledge or concern for which one the implementor chose it would be best. When possible the best solution is for a standard not even to sit in a technology stack at all, but to require the implementors to pick and use an appropriate stack (or stacks); this keeps popular standard from forcing people to use other weaker ones and it lets vendors actually compete by working with various stacks. Actually JDBC and ODBC are examples of this approach. They don't mandate that any particular kinds of wire protocols are used, they let the vendors work that out for themselves. Heck, neither one even mandates much about SQL. This rule is not absolute, there are plenty of standards that have become so dominant that presuming their presence is fine. TCP and IP have this quality, it's OK to presume them these days but most other standards are not so easy to presume.

The other cardinal sin of a framework standards is to tell you how your program should run. In Java or C this is taking away your main. When the standard dictates so much about your program that your program starts to look like an adjunct to the standard and not the other way around it has definitely gone in the wrong direction and is to be avoided. J2EE did this in spades. In fact I view App Servers as a whole as an unfortunate turn in the wrong direction. The same services could easily be provided as tools but instead you get an entire massive system whether you need it or not. Fortunately there are plenty of non-standard tools these days so we can all happily go back to ignoring the J2EE non-standard but Java Land wasted a good three years or more thanks to some very awful choices and almost an entire generation of engineers got to learn how not to do things before re-learning how to do them properly.

I should point out that I am not against frameworks. Frameworks can be a great thing and to the Spring/Rails/Tapestries of the word I say "go for it" with only the mild caveat that if you can produce independent components (as Spring does for example) that's double plus good. But anything as big as a framework is too big to be a standard. Way WAY WAY too big.

The rule of utility

"It's not a standard if it doesn't help you solve your problems."

This isn't really a legit standard for standards, but it's very important in how we view them. Do you need SOAP? Maybe, if it helps your program meet its goals; if it doesn't then it's a non-standard from your perspective and your perspective is the only one that matters. Think TCP sucks and you want to use IP directly that's awesome; do your thing. You're a big girl and you can decide who you want to take to the prom without mommy and daddy corporate entity picking your prom dress and telling you how late to stay up. Of course if you find out that you need guaranteed delivery and you waste nine months making your code work then the baby is yours and you'll be the one taking responsibility for it. Of course, as it turns out, the responsibility is yours either way.

Where do you get the right

By now some people may be wondering where I get the right to decide what should and should not qualify as a standard. Actually the real question is where does anyone (ANSI, W3C, AdHoc committee no. 481K-23) get the right? They get it from you. In the end standard adoption is a democratic process (or at least a capitalistic one) and all that committees can do is to offer up candidates for us to vote on. There aren't any rules about who can propose candidates and there aren't any rules that govern who you get to choose. My standard of standards is meaningless unless it makes sense to you and that means it's just as valid as T.120 or XSLT. All I'm doing here is pointing out that you do get to vote and like in all democracies your vote makes a difference and affects other people. Use your vote wisely and I shall try to do the same with mine.