Way back in the dark ages – AKA June of 2003 – my colleague wrote a subtle and understated but I thought very telling indictment of the traditional software infrastructure players, or more specifically their product marketing and design. In part he said,
Not every organization is a Charles Schwab or an eBay, but BEA and IBM tend to compete as if that were the norm not the exception.
This, of course, is just another manifestation of the problem that has led the drive to perjoratize the word enterprise with the term enterprisey.
What’s interesting, however, are the layers of belief that underly that problem. The drivers for producing complicated, expensive and yes, highly scalable, software are many – too many, in fact to list. But I’ve always wondered, usually in the context of discussions around dynamic language usage, if some of the folks building software understand just how deeply engrained some of these beliefs are.
To wit, I managed to find the time to listen to Jon Udell’s podcast with Day’s Roy Fielding on the train back from Boston yesterday, and Roy articulated something I’ve said before but never as succinctly. [1] At around three minutes and thirty seconds in, Roy said:
A lot of people think that when they’re building an application, that they’re building something that’s going to last forever – almost always, that’s false. Usually when they’re building an application, the only thing that lasts forever is the data – if you’re lucky. [2]
Before I continue, let me put this in context. One of my first gigs as a systems integrator was at a women’s clothing manufacturer in NJ (I’ll have to put up pictures of my cube there someday ;), and shortly after arriving there I was given responsibility for a variety of EDI, Inventory, Sales and Billing applications written in COBOL and which ran on top of a DOS/VSE mainframe (you read that right). I was horrified to learn, after perusing the very dusty and occasionally mildewed documentation for these applications, that most had been originally designed, coded and documented in the late 60’s. With rare exceptions like the EDI code, most of the running applications were some thirty years old by the time I got my hands on them. So I do know just a little bit about applications that outlive their predicted lifespan.
But I’d also submit that for each one of those major applications that will survive for decades, I probably wrote 5-10 smaller one off or small-scale applications. “I need a report that produces X,” “We got bad data from Y, and I need that cleansed and normalized,” “We completely lost our data volume for applications a, b, & c and our backup’s four days old. We need to rerun the batch operations with our sales data for the last four days,” “We need a local application, complete with database and GUI, that will store and index problem calls for on-call personnel” – and so on. With rare exceptions, I used an entirely different set of tools to solve this set of problems.
As Fielding discusses in the podcast, however, there’s a common institutionalized belief that if any given architecture is good at solving a certain set of problems, it must by definition be adept at solving entirely different sets of problems. Like Fielding, I’m not a believer in that line of thinking.
None of this, of course, is brain surgery. If all of this sounds like a “use different tools for different jobs” argument, that’s because that’s precisely what it is. This realization is reflected in the increasing adoption, just as one example, of PHP within organizations such as IBM and Oracle that have made massive investments in the Java platform. But I think that Fielding’s comments are important because they highlight the fact that recognizing that there’s a market for PHP does not in any way imply an understanding of that market.
The dynamic languages, PHP included, may be so called because of their design and convention, but the term is apt in another respect: the applications built on top of them tend to be dynamic in nature, and not terribly long-lived. Put simply, I’m contending that there are fundamental differences between your average PHP, Ruby, etc application and a typical Java project. Some dynamic language projects, of course, may survive for decades or more, but the majority are designed for considerably short lifespans than, say, their Java counterparts. Understanding the dynamic language market, then, requires the ability to use a different lens to view the world. Where Java developers might think in terms of decades or years, dynamic language developers might be thinking in days or hours. This is a crude if necessarily blanket distinction, but not one that I feel is terribly unfair.
It’s not going to be enough, IMO, for ISVs and other interested parties to merely be aware of the opportunity that the dynamic language market represents, because the gulf between the different communities is wide and the primary wellspring for the intermittent friction. They must come to terms some fairly elemental differences in approach, assumptions, and design. The same types of differences, as an example, that make Ruby on Rails (or DJango) a compellingly unique solution to a particular type of problem. The differences must be internalized, not kept at arms length – embraced, not feared. At the most basic level, enterprisey vendors must care as much as the Rails folks do about next week, rather than the next decade.
[1] Just for the record, I wanted to note that Fielding did not specifically tie his argument to the question of dynamic languages. I’m using his remarks here to make my own point, although I thought his response to Udell’s question of “Why Java?” was interesting even if the question was – as Jon noted – facetious in origin.
[2] While I’ve selected this one quote, I highly recommend listening to the entire podcast. Fielding discusses, among other things, his ideas about replacing the protocol that he’s responsible for inventing – HTTP.
