Specifications and Standards: The Good, The Bad, and The Ugly

I think our industry might soon have more specifications than stars in the known universe. Fortunately, even if we run out of meaningful names for them, we'll never run out of UUIDs. Goodness knows many modeling types just love their UUIDs, even if a UUID does use up more space than the object it's identifying; but I digress. Not surprisingly, there's even a UUID specification, so we can be absolutely certain that no two specifications nor two modeled objects need ever unintentionally use the same identifier. It would really be a fly in the ointment for there to be confusion, it would be very antithesis of what specifications are all about.


Specifications and standards are the cement that props up and binds our growing, global software edifice without which we'd be using an abacus or slide rule. And of course in this day and age, there's nothing finer than an open standard, given that being open, like motherhood, is simply an unassailable virtue. To get a good sense of what specifications are all about, just have quick glance at this this poster:


Clearly standards help to simplify the lives of users and developers alike by precisely spelling out expectations for well-defined behavior so as to facilitate interoperability. I know this poster is exceedingly lovely and that you can't truly appreciate all the virtues of the fine print unless you render the original PDF on paper the size of a wall poster, but please don't do that, the world's trees are disappearing at an alarming rate already and it would be very sad if standards contributed toward global warming and the loss of wetlands.


Now don't get me wrong. I'm not suggesting that specifications and standards are simply bad, I'm merely suggesting that they aren't pure virtue. When entire organizations such as WS-I are dedicated to cutting out the cruft produced by other organizations, something has obviously gone more than a little wrong. In fact, standards are even used as political weapons. Can you think of a better way to tie up your competitor than to have them wasting their time implementing a tainted specification rather than spending their time wisely on something innovative and hence competitive? Standards can be a great way to enforce mediocrity.


It should be clear that standards bodies are not the place to innovate new things. It should also be clear that while large organizations might look like bottomless pits of resource, their massive inertia makes it difficult to turn on a dime. Hence they tend to thrive on standards and often more so than smaller organizations. Innovation thrives on agility and the willingness to explore radical new ideas, while standards and specifications, when working properly, thrive on codifying well-established best practices; this dividing line is too often blurred these days so it's best we remain vigilant about the flies that might get into the ointment.


I particularly love working at Eclipse because it's the kind of place where the two worlds meet. Most gratifying of all, at Eclipse the committer is king; specifications are just a tool, a means toward an end, rather than an end unto itself. Developers know politics when they see it, and the good ones, when given a choice, will focus on implementing innovative things, even if those aren't yet standard things. We can let politicians worry about standardizing innovations after the fact, as should be the case in the natural scheme of things.