Slashdot Mirror
Are There Too Many Standards?
CyNRG asks: "Lately, I've been reviewing the different programming and protocol standards in an effort to guide my career in the most fun and profitable direction. The proliferation of standards is astounding! Choosing which path to follow is more like a trip to Las Vegas. Standing at the craps table in Ceasar's Palace at 3:00 am: do I play the point? Big 6 or 8? Play the field? How about covering the hard ways? The world is using technology more and more, so I would expect more standards based on that fact. It seems like common knowledge, vis-a-vis Microsoft, that companies try to put forth 'standards' in an roll of the dice to make their 'standard' defacto. Are there too many standards?"
Set your standards a little lower, and see how that works out for you. ;-)
while true ; do echo this is my sig; done
You should choose either "Pass" or "Don't Pass", bet the maximum odds you can after the point is established and do the same for two "come" or "don't come" bets.
This will give the best odds to walk away a winner (with the house keeping a razor thin edge).
The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
What examples are there of too many _open_ standards causing a problem?
Avoid the hard way bets and big 6 or 8. Play the pass line and odds bets. Maximize the latter.
-- $SIGNATURE
Actually, the people saying that there are too many standards often have a new one in mind that encompasses or does the same thing as a few others so that he can say "if you just use my standard, you only have to use one and not three!" So yes, it can and will get worse.
OK, that may not seem like a popular idea, but in the long run, it may be the best path to follow. While it could certainly be argued that there are too many "standards", the important thing is to become proficient with follow the "accepted" ones. You say you are reviewing different standards to help guide your career path. My best advice is to learn the basics, and learn them very well. Learn not only how they work, but how they work together. Yes, you will become more of a generalist, but you will also become proficient at determining how you can develop a solution by applying your knowledge that can best fit the given situation.
Focusing on a specific standard IS a crap shoot. Yes, you could make big bucks by jumping on the latest bandwagon, but it will no doubt be short-lived. Over the long haul, a broader knowledge base is more useful and marketable thatn a highly-focused one.
My mom always said, "Jim, you're 1 in a million." Given the current population, there are 7000 of me. God help us all!
I get the impression the submitter feels overwhelmed by the volume of standards and wishes his learning curve was less steep.
I think what he doesn't understand is that without the standards there would be multiple non-standard implementations.
To the submitter: Try looking through some established electrical, plumbing, and building codes. Imagine building a house without them. Then maybe you will understand why standards are a good thing.
When will Windows be ready for the desktop?
The problem isn't with the quantity of standards, but the quality of specific ones. Standardization itself makes sense in a lot of cases, but sometimes standards are indeed made for the wrong reasons, or over-architected into oblivion (ie. SOAP + WSDL + UDDI + how many SOAP security standards) which makes the barrier to entry for compliance with those standards far too high to expect most people to bother.
Another problem is that a failure of some parties to properly adhere to the standards causes those standards to become less useful as well (read: MSIE vs. Mozilla, inconsistent HTML support, partial CSS support, JScript vs. JavaScript). This is sometimes even made possible by the standards themselves, by being too vague, which necessitates a level of "interpretation". It's also not always strategic for companies to follow standards -- they prevent lock-in, they make it easier to lose your customers to your competitors, and that can actually decrease the value of your products by giving your customers something to hold over your head during price negotiations. Standards need better incentives to get companies to actually buy into them, as opposed to just saying they are and then going and making their own "standards".
The other problem is that standardization, especially when the industry is in the middle of such a pro-standards push, often comes too early in the life of a given technology, resulting in a standard that doesn't account for the whole problem yet. For example, RSS was declared a standard before it was ever really adopted, and then some limitations were found in it that to fix would break backward compatibility. The result is a number of incompatible competing standards (RSS 1.0, RSS 2.0, RSS/RDF, Atom, etc.). SOAP and XML-RPC both did the same thing, and the result is that it's a pain in the ass for developers to support them, due to certain limitations in their designs (array support in SOAP, reflection as an afterthough in XML-RPC, etc.). SOAP and XML-RPC also resulted in a 3rd competitor as well, REST.
So my answer would be that there aren't too many standards, but that standards are just like anything else: not necessarily applicable to every situation. Use proper discretion. Neither extreme (all standards vs. no standards) is a good thing.
putfwd.com - 1GB Free file storage with a twist
I believe the problem arises when standards are written before being tested in the wild and without using time-tested techniques.
This was the problem with EJB. All these companies implemented the standard, but the standard that had never been tried before. Only now, are people realizing what a mistake it was.
With the various XML standards, time wasn't allowed to work out the flaws, and to allow various standards to merge. So, we have a bunch of standards and none of them are quit right.
How does a spec become a standard? People recognize the relative benefits of a spec versus the proprietary advantages of doing it their own way. Since standards tend to emerge in discrete verticals, there isn't a dilution of this benefit.
It would not be incorrect to say that a "standard" is really an honorific applied to the spec that won in the marketplace of ideas. If the discrete vertical you chose to be the "standard" in is trivial, then it will be a pyhric victory. If it is non-trivial, even if a better idea comes along, you will have a marked advantage as the "incumbent" standard. (QWERTY vs Dvorak keyboard layouts as an example). Eventually, if enough people see the benefit vs the advantage of the existing standard... new standard.
...But I digress. TREMBLE PUNY HUMANS!ONE DAY MY SPECIES WILL DESTROY YOU ALL!
Three acronyms for ya:
CRLF
CR
LF
We have three major computer platforms, and three different standards for the line terminator in plaintext files.
Of course there are too many standards.
As long as you do the same, you should be ok.
perception is reality
Exactally, the problem isn't too many standards. Standards are a good thing. The problem is too many proposed standards all vying to become the standard. Companies rarely work together on this sort of stuff until it becomes absolutely necessary to do so (i.e. their proposed standards fail).
I do agree that there are rather more ways of doing the same thing than you might expect, and compatibility between standards has (generally) been poor. Here are some examples. (The list is not intended to include everything.) You'll notice that a lot of the standards are extremely specific. There aren't many "general purpose" specifications out there, and those that exist (eg: SGML) tend to sacrifice fine control in favour of expansive capability.
(I'm not even going to try to document the few thousand IETF specifications and notices that exist. Of what is described by the IETF, how much is actually used in practice? Probably not a lot. Now, that's fine in that case, because the IETF is not writing these as press releases for products they're planning. It's much more a research and deveopment environment. In R&D, not everything works, but if you want to avoid repeating mistakes, you catalog those just as efficiently as your successes)
Authentication Systems:
Parallel Processing (running two or more processes in parallel, in such a manner that they can communicate with each other):
Library-based
Application-based
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)