In the last few days I’ve read a few articles on the programming reddit that have dealt with technology hype.

rnrn

In the article XML Backlash? Brennan Spies looks at the achievements of XML, and how its position may be under threat from newcomers like JSON and Google’s protocol buffers. Nothing new there – I’ve been warning of the shortcomings in XML for years – before it became a popular passtime.

rnrnrnrn

Assaf Arkin muses on SOA and the statistical non-FAIL showing that SOA has not improved project success or ROI. I particularly liked the InformationWeek statistic that “58% said their SOA projects introduced more complexity into their IT environments”. Damning, but hardly surprising. Assaf’s conclusion is that new technologies are not protecting us from failure, but enhancing the abilities of the successful teams to do more.

rnrn

Damien Katz wraps up with REST, I just don’t get it wondering why REST should make sense in a world that finds POST/SOAP sufficient. Most of the commenters seem to miss his point: “there is nothing wrong with a plain old POST as an RPC call … keep it as simple as possible and be done with it.”

rnrn

Assaf predicts that REST will be getting a bad rap on the business front within 5 years, and the commenters on Damien’s blog should give us an insight into why this will happen: dozens of developers are dying to jump onto the new ship without understanding it, or its relative advantages and disadvantages — it’s a shiny new ship damnit! We don’t need to know!

rnrn

So in the one corner we have the bell curve working against us: the majority of developers will follow a technology trend because the hype tells them it is good, and they don’t have the breadth of skill or experience to perform an evaluation themselves. I suppose I’m saying that cargo cult programming is the norm – and that’s another of the recent themes on reddit.

rnrn

In the other corner we have management, also without the necessary technical skills to avoid falling prey to hype, but mindful that “No One Ever Gets Fired For Buying IBM”. The safest approach for a manager is to mandate the use of popular (contemporary, hyped) technologies. And so we will soon see REST added to the popular Java/J2EE/SOA/XML stack as this year’s best practice.

rnrn

And REST will enjoy widespread use and fame, and the ROI will be uninspiring, and the project failures no less frequent, and fame will turn to infamy, and REST will join history along with CORBA and COBOL and RDBMS and the other legacy technologies that we still rely on but don’t like to talk about.

rnrn

And we will continue to wonder what went wrong.

rnrn

Let me tell you.

rnrn

First, we’re so concerned with the enabling tools that we can’t improve the information technology. The users of the software we develop – those cogs in the corporate machine that gathers revenue and grows wealth and pays our salaries – don’t care about SOA or REST or XML. They care about how the technology at their disposal (that’s your software) makes their jobs easier or more productive. Improving your enabling tools does not automatically translate into improved technology for the users.

rnrn

Second, humans are terrible at risk assessment. We can’t plan, and our ability to grasp complexity is poor. To compensate for this we turn to a framework (like, say, SOA or REST or XML or patterns) to provide the ability to extend our solution in the future. But we fail to ask whether we really need such a framework – if indeed the hyped framework in question is appropriate. And so in our desperate uncertainty we choose to add complexity just in case the problem turns out to be more complex than we had planned.

rnrn

As for REST, only a few people on Katz’ blog really get it. Scalability, cachability, efficiency and other -ys are results of this approach and are not unique to it, nor is REST presented as an alternative to RPC. In the words of Roy Fielding (he’s the guy who created/defined REST):

rnrn

The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components. By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application’s needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.

rnrn

Strange how vocal proponents can enumerate the benefits of REST in the case of HTTP without understanding the limitations, or that REST isn’t a silver bullet, or even that REST does not presume the use of HTTP.

rnrn

Or that using GET in an AJAX application opens you to script injection attacks that will deliver the content to an attacker, so you never want to use GET to retrieve sensitive data, even over SSL … but that’s another story :)

rn