Historically Bad Ideas in Software
March 2, 2009 - 11:56pm — bex
At the QCon convention in London this year, they have an interesting track: Historically Bad Software Ideas. I love the concept... put together a list of ideas that seemed good at the time, and some people probably found useful. However, in the end they were Really Bad Ideas that cost billions of dollars.
The historically bad ideas are as follows:
- Remote Procedure Calls: including things like DCOM, CORBA, EJBs, XML-RPC, and SOAP... all of which are fundamentally flawed. Integrating remote systems will always be tricky, and you aren't doing anybody any favors by trying to make a remote system seem local. We would all be better off if deveopers were forced to memorize The Fallacies of Distributed Computing, and then deal with reality. Look out, ReST, you're about to be ruined as well if you're not careful... Or so says Steve Vinoski, the author of many books and articles on RPC.
- J2EE: Enterprise Java filled an important niche when developers wanted to flee from proprietary systems and APIs into some kind of standard middleware. But, as those Java systems became slaves to committee-driven standards that focused more on selling software than empowering developers, the developers again fled to open standards, open source, and Plain Old Java Objects... Or so says Rod Johnson, the inventor of The Spring Framework
- The Null Pointer: multiple, multiple, so many reasons why this is a billion dollar mistake... If compilers never allowed you to compile pointers that might be Null, how many problems could have been avoided? Several billion, at least... Or so says Tony Hoare, the inventor of the Null pointer.
- Architectures that ignore multi-core, parallel, virtualized environments: Not so much a billion dollar mistake... but a billion dollar wasted opportunity. Developers have to stop thinking about serial processes one box, and start thinking in terms of a massively parallel cloud... Or so says Oracle Vice President Cameron Purdy, from the Coherence team (a truly impressive product, IMHO).
- Software Standards: My personal pet peeve is the requirement that everything -- and I mean everything -- be a "standard." Obviously a good standard is always superior to a good API... but a good API beats a mediocre standard any day of the week! Too often the process involved in creating a "standard" is premature, political, overly rigid, and just plain awful at serving the needs of the end users... Or so says Paul Downey, who has worked on OASIS, WS-I, and W3C standards.
Naturally, some of these talks are going after some sacred cows... I'm sure a number of my readers are fans of SOAP, J2EE, and Standards, so I anticipate these talks might trigger some controversy in the enterprise software world. So what do you think? Which "Historically Bad Idea" might be getting a bad rap? Which additions would you make to this list?
Couldn't agree more with the
Couldn't agree more with the ones put forward so far.
The IT industry is still paying the heavy price of those deranged ideas. I know how much I wished I could twist the neck of the EJB and J2EE morons, who made my life a misery for years following the y2k debacle!
I'd like to add one at least: the notion that active clustered db servers can be efficiently set across more than one physical site separated by considerable distances.
Microsoft and some of its followers are trying to push this one heavily and it is as deranged as can be...
good addition...
I'd like to add one at least: the notion that active clustered db servers can be efficiently set across more than one physical site separated by considerable distances.
Woah... people are actually trying to do that??? Jeez... what's wrong with federation? Or asynchronous processing? There's this little thing called "The Speed Of Light" that we will never be able to get around, and geographically distributed database clusters really suffer because of it.
Personally, I believe that lumping SOAP with RPC is a tad unfair... SOAP's initial goal was loose binding between systems. But, as they mashed more and more things into the SOAP spec, and the tools became harder and harder to use, it became more and more like RPC. There's nothing wrong with "Classic SOAP," but the modern varieties do suffer from the same limitations of all RPC-centric solutions.
I agree
Each of the technologies mentioned above has solved a problem, but more oftentimes, it solves the problem with way too much effort. I remember my first days working with SOAP, when I barely knew XML... Talk about much ado about nothing. The payload is all you are really interested in, and you had to go many levels deep with multiple namespaces (it didn't help that the SOAP payload was NOAA's NDFD, and I was using Apache Cocoon).
I'm not a huge MS proponent, and their .NET API has more than enough stupid things in it, but I think it shows the idea of a good API not build on standards can accomplish quite a bit (yes I know C# and even the .NET framework have ECMA standards, but I also know who wrote them). Writing a very powerful, expressive, and even multi-threaded application in C# is a lot easier than equivalent in Java.
What is interesting is the idea of spontaneous standards. Ones as the source stated: "Standards arise from consensus between competitors signaling maturity in a marketplace." Eventually all the players see how cooperation benefits everyone (Microsoft has had a hard lesson at this, but you can see their business modal changing). It makes me think of F.A. Hayek's application of spontaneous order on markets, where order emerges out of a natural process. In effect that exactly what is happening when a standard emerges from the process of sharing ideas in a cooperative environment. The 'Dark' formal standardization is akin to using 'force' (article even says 'war'), which is exactly what happens in a coercive state with central planning (socialism, communism, fascism). The difference here is that no one holds a gun to your head to use JSR-170 (at least not at any company i've worked at!). The parallels are striking.
standards are not "intelligently designed," so they must evolve
It makes me think of F.A. Hayek's application of spontaneous order on markets, where order emerges out of a natural process.
Good point... decent standards need to slowly evolve AFTER a market has reached maturity, and not BEFORE. Too many times people want to force a market to maturity by creating a standard, because then they have some kind of "control" over the direction of their competitors. However, then you just end up with something awkward which is outdated before it is even released, and few people use it.
Case in point, the previous content management specs were just plain awful... the definition of "content management" changed rapidly, and its only now settling down. I'm hopeful that the market is mature enough now so something like an extensible version of CMIS might get traction.
What about "write once, run everywhere"
What about adding WORA "Write Once, Run Anywhere" to that list? We've been chasing interoperability for a long, long time in computing...
I agree wholeheartedly on the null pointer and RPC. Oh the pain, the pain!
Languages Expressed in XML -- Awful
Great list. I'd add to that list any and all languages expressed in XML, which of course would include XSL. I can't imagine a more verbose and hard-to-read "language" format than XML. Languages should be crisp, terse, and easy to read; otherwise they're hard to debug and maintain. Languages are ALREADY hard enough to debug and maintain. Why express them in a data format? Angle brackets should mean greater-than and less-than, not "here's an element boundary."
I'm tempted to add Garbage Collection to the list. I'd like to think GC can be made better (that it's just an implementation problem), but I am starting to think that there's a nasty coupling between GC's inherent value, on the one hand, and the nondeterministic aspects of GC that give so much trouble on scale-up. In other words, the very things that make GC so useful are the things that make it so horrible when you try to scale. The two are related, hence nondeterministic GC is unfixable in some sense. It's certainly a horrible thing to watch your machine freeze up unpredictably as the GC runs. Especially if you were counting on that retro-rocket to fire at just the right moment on reentry...
Re: Languages Expressed in XML -- Awful
I totally agree...
Do you know about ANT? Its the Apache build tool that developers love... it uses some horrible kind of "programming language" expressed in XML. I recall Alec, Pete and I met its inventor (James Duncan Davidson) at a conference. Alec accosted James and said, "where are my frigging LOOPS?"
James laughed... I asked him if he had to do Ant all over, what would he have done differently? He said -- to our pleasure -- that he would have NEVER used XML in the first place. He would have instead used a commonly used scripting language instead. Ruby Make (RAKE) and Raven are closer to his original goal...
The move to latest and greatest technology
Despite the valid points being made, there are of course many benefits and advances made in software development, and thus many reasons for jumping on the bandwagon, which is why many of the mistakes made - listed above - are made. There is always the rush to the new, untested and untried technology, which then gains a momentum and acceptance without having ever delivered real benefits. Therefore I would contend that one of the biggest mistakes made in software is the rush to the new - instead of the sticking with the more slowly evolving old technology. How many old systems that were performing a good job were scrapped to make way for the latest and greatest solution - that turned out to be a flop.
Perhaps this means that the toughest job is trying to select those technologies that will work - and that won't turn out to be a dead-end - a tricky choice when you are trying to stay one leap ahead of your competition.
re: The move to latest and greatest technology
I frequently say, that the return on investment for software is a lot different than for other kinds of technology...
There is value being an early adopter, because you start automating processes before your competition. You use the web first, you use middleware first, you use cloud computing first, etc. You can do things your competition cannot, but you need in-house talent to evaluate and maintain bleeding edge systems.
There is value in being a late adopter, because you benefit when complex software becomes a commodity. Enterprise systems that cost millions a decade ago now have open source alternatives with fewer legacy challenges... even if you choose to install the same SAP application from the 90s, then you benefit from all those years of "lessons learned," and can do so for a fraction of what your competition spent.
What sucks is being a follower. Talent is scarce for cutting-edge technology, so you probably don't have employees with enough training. Also, you lack the ability to "coast on momentum" that some of the bigger late adopters have. Unfortunately, this is where most companies lie... so they have the deadly combination of not having the right talent, not having "best practices" to build upon, plus the panic of "we have to do this now or we'll be bankrupt!" All together, this leaves them vulnerable to people selling "historically bad ideas"... and since these companies are the majority, those bad ideas spread like wildfire.
Classic market failure... and I'm not sure if this problem can be solved...
It is a very controversial
It is a very controversial opinion to my mind. But I have to agree with some of these historically bad ideas. Of course remote procedure calls was a very bad and unnecessary idea. I don't know why they are done at all. But I don't agree with the opinion that J2EE is a wrong idea. It is a brand new java platform which will let us to make some interesting applications in the future. But despite the fact that I am Java fan, I have to agree that there is a sense in these bad ideas. I mean this top 5 is not a wrong one. Thanks for the great post. I will be waiting for another great ones from you.
Sincerely,
Robert Manton
Post new comment