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?"

Comments

The answer to your question is...

[node 3]

No.

Answers

[antizeus]

Avoid the hard way bets and big 6 or 8. Play the pass line and odds bets. Maximize the latter.

Not the Right Question

[lux55]

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.

Standards

[jd]

Personally, I became a generalist. It has been a two-edged sword. Some potential employers look at me as though I'm from another planet. (Since more than a few of those look as though they came from the "B" Ark, that might be a compliment. :) Other potential employers look at my diverse skillset as a considerable asset. After all, they can get me to do more, with less training.

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:

• Certificate (usually X.509 or some derivative) - the user and/or the computer carries some pre-generated, stored "proof" of their identity
• Token-based (eg: Kerberos) - you connect to some "independent" authentication system which gives you a token which authorizes you to use other systems
• Password (the standard method) - this can include biometrics, swipe-cards or PIN numbers, as well as the usual "type something in" method
• Challenge - the user is presented with some dynamically-generated query and must product some response.
• Some combination of the above (eg: S/Key uses a challenge as a key. It then applies that key to perform a one-time encryption of the password, which is essentially unbreakable)

Parallel Processing (running two or more processes in parallel, in such a manner that they can communicate with each other):

• Client/Server systems - standard, easy to write, and very popular when clearly-defined roles exist
• Customized language - popular in certain segments of the industry, as the performance tends to be greater than by other methods
  • SISAL - implicit parallelization. The compiler will figure out how best to divide the software
  • Occam - supports explicit parallelization, at runtime, and process mobility
  • Parlog - supports explicit parallelization
  • Parallel C - Ditto
  • Java + RMI - provided each Java application is running independently
  • Any language with OpenMP extensions - OpenMP is a replacement for Threads, System V shared memory and message-passing systems.
• Kernel-based SIMD (eg: SMP)
• Kernel-based MIMD
  • BProc (ie: Beowulf) - allows simple process migration
  • Mosix - migrates processes to machine with lowest load
  • Classic MOSIX
  • OpenMOSIX

Library-based

• PVM (fixed number of nodes)
• Message Passing Interface (dynamic number of nodes)
  • MPI-1
  • MPI-2
  • IMPI
• Corba - This model allows services to be located by reference, rather than by location, but otherwise is simply a method of calling a function inside of one program from another program.
• POSIX Threads (generally not networked) - A fairly low-level multi-threading system, providing support for simple synchronization, message passing and other basic functions
• System V IPC - a crude method of handling semaphores, messages and shared memory, but it's extremely portable and relatively easy to write for

Application-based

• Cactus/Thorns
• Globus
• Portable Application Code Toolkit

Re:Three acronyms

[Bombcar]

And that originally comes from typewriters, which have both a "Carriage Return" which returns the typehead to the beginning of the line, and a "Line Feed" which moves the paper one line. :)