What I find fascinating is that you almost never hear those same people say, "Oops, we messed up." I've always wondered what happened to all those people who were predicting the apocalypse for Y2K. These people had paid to hear some speaker tell them that "there were chips in everything, so all the trucks, water pumps and electrical stations will stop working at midnight on Y2K." These same people would never listen to me, who had programmed embedded systems and so knew that many of those systems didn't even know or care what time it was.

The one or two people I knew who went around trumpeting the impending disaster were not apologetic or reflective on January 1, 2000. They simply moved on and found something else to predict doom about.

I remember when the OMG (the body that created CORBA) first started. To be a member you had to be a corporation and pony up a large fee each year. And CORBA itself always made me feel stupid, like I must be missing some essential epiphany that would unlock its complexity. A part of me, which I've learned to trust over the years, kept telling me not to bother learning the complex details of CORBA, and the only time I ever actually created a CORBA client, it was in Python, so it was actually easy.

So I found this article to be quite an interesting analysis of CORBA's history, and of committee-driven specifications in general.

After the author has analyzed the rise and fall of CORBA, he proceeds on page 4 to consider lessons we might have learned from the CORBA experience. I would summarize his analysis to say that:

A standards body should formalize existing practice, rather than inventing new practice without experience.

I spent roughly 8 years on the C++ Standards Committee, and I remember that this was one of the initial goals of that committee. Although invention did happen, it was relatively small and careful compared to CORBA and other standards which were created from scratch, without experiments or implementations to ground it in reality. (And before you complain about the complexity of C++, virtually all the issues of the messiness of the language can be tracked back to "backwards compatibility with C," which has always been both the boon and the bane of C++.)

Another example: the original EJB design was based on a purely theoretical model of the way "enterprise software" would be built, and the roles and tasks of the people involved in that process. It turns out that these roles never actually happened, and so the design of EJB -- intended to make those roles easy -- added so much unnecessary complexity that, after an unpleasantly long time, it was completely redesigned in EJB3, based on actual practices observed in libraries like Hibernate and Spring.

I found the most interesting quote in the article to be this one, on page 4:

"Web services, the current silver bullet of middleware, uses a process much like the OMG's and, by many accounts, also suffers from infighting, fragmentation, lack of architectural coherence, design by committee, and feature bloat. It seems inevitable that Web services will enact a history quite similar to CORBA's."

Web services have definitely given me that funny "hmm, maybe not" feeling. And my experiences programming against the Fedex and USPS computers (see previous weblog entries) don't inspire me with confidence, because if SOAP or whatever is so great, why don't they provide it? (And I will point out, again, the irony of every web services article and book using Fedex as an example of why we want web services.)

Web services do seem closer to things we actually want to do that CORBA did, but the complexity of SOAP, for example (and its apparent decline in the world before it has even gotten out of the starting gate), is not particularly promising.

And the clincher is all the over-the-top fanfare that web services rode in on. When the marketing people are more excited about a technology than the techies are, chances are it sounds better than it is.

Of course, the fundamental idea of web services is a good one. We really do want to be able to extract useful information from a remote site. That's happening, and it will continue to happen. But it must be simple, because even if programmers are smart and can figure things out, the CORBA experienced proves that we don't want everything to be as complex as it can possibly be.

Programming is all about abstraction, and the abstraction here is the remote procedure call. I want to be able to write some kind of simple function call, and get some information and maybe produce some kind of side effect on the remote computer. If the underlying mechanism happens to ship data back and forth using XML, or uses an XML-RPC, SOAP, or JSON setup to make the call, that's fine -- but I'm solving a real problem here and I don't want to have to spend my time figuring that stuff out, or even needing to think about it.

The system that provides remote procedure calls, spans the space of calls that need to be made, and that keeps it simple to implement and use on both the client and the server, will be the one that wins. At least I hope so, and in the flattened world of the internet, I think it has a better chance now than it ever did in the past.