A Standard is Only As Good As Its Implementations

There are many potential advantages in software development when adhering to standards. These advantages include the ability to shift between implementations of a standard, the ability to connect two disparate pieces of software together when both meet a standard, a greater pool of developers with knowledge and skill from working with different implementations of the standard, and greater access to literature and other resources on the standard. I called these potential advantages earlier because they are not always realized. In fact, most of these advantages can only be gained if there are multiple implementations of high quality and high degree of standard conformance.

For example, if there is only one good implementation of a standard, then there is no real ability to switch between implementations of that standard. You have no more freedom in such a case than if you used a non-standard approach. Likewise, if there is only one or two strong implementations of a specific standard, you are less likely to enjoy the benefits of a larger skill set and greater availability of related literature than a popular non-standard product might enjoy.

So why does all of this matter? Because too many developers (and I have made this mistake myself before) say things like, "I know its not the best, but it's the standard." I do like to work with standards when possible, but not at the cost of many other positive features and characteristics, especially if I cannot really enjoy the benefits of standardization because there is only one or a very small number of decent implementations of that standard.

In fact, de facto standards can be just as useful if they are widely popular. For example, Ant, Maven, Struts, and the Spring Framework are not themselves standards, but they enjoy many of the benefits discussed above (wide developer talent pool, wide literature set, etc.). Many of these products, especially Spring, are heavily standard-based even if they are not themselves standardized.

The DHTML debacle that is the effort to write Ajax/DHTML applications for highly incompatible major browsers (due to lack of HTML/CSS/DOM/ECMAScript standards implementation) is evidence that standards and standards compliance do matter and do make our lives as software developers easier. It would be nice if the major browsers were all more standards-compliant (and Microsoft Internet Explorer 8 may help with this), but until then I prefer using Flex or OpenLaszlo so that I don't have to worry about browser standardization. It is more important for me to enjoy the benefits of standard code provided by Adobe (Flash) or Laszlo Systems (Flash/generated DHTML) than to cling to a claim of using web development "standards" that really aren't so standard. The problem of the incompatible browsers really comes down not to problems with the underlying specifications, but rather is such a big problem because of the lack of compliance of the major implementation of those standards.

Unfortunately, standards can only be as good as their implementations and the most dominant implementations are not always the best or even good implementations of these standards.