Overall, the OMG's technology adoption process must be seen as the core reason for CORBA's decline. The process encourages design by committee and political maneuvering to the point where it is difficult to achieve technical mediocrity, let alone technical excellence. Moreover, the addition of disjointed features leads to a gradual erosion of the architectural vision.
We've chatted with several people recently about building complex and large systems -- Vista, Eclipse, etc. -- so this article is great background for that discussion.
Standard Snags
It highlights the chief issues with vendor driven and "industry" standards:
Quarterly pressure driven commercial interests rarely align with what's good for the community: developing a lesscode/lessconfig standard.
Meritocracies, as snooty as they are, are one of the only ways to assure you don't end up with crap.
The most damming error is summarized towards the end, not playing well together:
At the heart of these open source practices are two essential prerequisites: cooperation and trust. Without cooperation, the evolutionary process cannot work; and without trust, no cabal of experts can act as an ultimate arbiter. This, however, is precisely where software consortia find their doom. It is naïve to put competing vendors and customers into a consortium and expect them to come up with a high-quality product—commercial realities ensure that cooperation and trust are the last things on the participants' minds.
Emergent Standards
I, of course, prefer de facto standards that later become formalized into official standards: JavaScript, the weird life of HTML, microformats, and other "small" standards that end up getting hammered out in the real world instead of committee. My code-faith has evolved from being a strongly typed nut-job to preferring technologies that are agile enough to go through countless iterations trying to get it right.
CORBA's numerous technical flaws have accumulated to a point where it is difficult to fix or add anything without breaking something else. For example, every revision of CORBA's interoperability protocol had to make incompatible changes, and many fixes and clarifications had to be reworked several times because of unforeseen interactions with features that were added over time.
Highly Trained Monkeys Only
Now, part of this, as the ever pragmatic and insightful Kinman taught me, is keeping the idiots away from your code: 'cause they're the ones who rigid systems are designed to protect your code from. If you can't keep the less than meritorious folks away, then you have to start bringing in the process, the strong typing, and The Almighty Thud. But, always keep track of how far away from the sweet spot of programmer salary and expenses for defensive development tactics you use: you can't afford all rock-stars, but you can't afford all Right-click Coders either.
But, back to standards. Using an emergent technique is a lot more chaotic at first, but when you don't get Pancho and Lefty'ed, you end up with a free and clean standard that has running code to prove it works. I'm not saying don't do standards -- hardly, this is RedMonk you're reading after all ;> But I am saying that standards deriving from existing systems have a much higher chance of being successful and surviving than those create big-bang style. It's obvious, right? And yet, it doesn't seem to be followed as much as you'd hope, especially behind-the-firewall.
The advice here is this: show me running code and a users before you convene a standards committee.
Previous Topic
