Dynamic Indeed: Application Lifespan and Understanding Dynamic Languages

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

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.


  1. > Put simply, I’m contending that there are fundamental differences between your average PHP, Ruby, etc application and a typical Java project.

    I’d say that the one off, short term type of work that you describe is not being done in PHP or Ruby, but .NET which has replaced VB. This has more to do with .NET tools and third party support than the static/dynamic nature of the language.

  2. christopher: i agree, and should have put that more strongly. in my experience, the dynamic languages are employed quite often for these types of needs – as is .NET, as you point out – but it’s not because they’re dynamic (necessarily). the reasons are varied, but usually include have something to do with barriers to entry like complexity, cost, and availability. in other words, i’m using dynamic languages in this case as a descriptive term, a bucket if you will, rather than as a symbol of why the languages i’m throwing in there are successful.

    where we might beg to differ is on the .NET v PHP, Ruby, et al bit. as mentioned above, .NET technologies are certainly a big part of that conversation, but i see an awful lot of PHP, Python and so on employed as well.

    i’m not discounting the presence of .NET, and certainly not the rampant success of VB years ago, but neither would i discount the growing popularity of some of the so-called scripting languages. different tools for different jobs, as they say.

  3. > I’m contending that there are fundamental differences between your average PHP, Ruby, etc application and a typical Java project.

    I’m sorry to keep coming back to this quote, but do you mean intranet web apps, command line apps, or external web apps?

    Don’t get me wrong, I think there is a lot of genius in Python, but I don’t think I approach python apps that much differently than I do C++ or Java apps. Sometimes my python and C++ apps are one in the same.

    I totally agree that there is value in the quick and dirty and vendors should support that paradigm, but I don’t necesarily see that tied to tool selection. The Unix command ‘tail’ for instance is a tiny app written in C, but it could have been written in any language.

  4. I tend to agree with Chris. The choice and use of language seems completely separate from the longevity of the application itself.

    What am I missing? Is this the right interpretation of the post?

  5. chris & brandon: interesting. i think we may have a scope problem, but let’s find out.

    am i to understand that neither of you really sees any disparities between languages in terms of productivity and speed? in other words, given a quick and dirty job, it’s just as easy to knock it out in C++ or Java as it would be in, say, Perl or PHP – assuming equal language facility? there’s no delta in development speed? if so, i can’t really agree with that. there have been reasons over the course of my career that i had to develop in things like C, COBOL, or even – shudder – Assembler, but i would never try to argue that i could develop as quickly in those languages as i could with some of the more recent developments. hell, even compared to ASP – not ASP.Net – Ruby’s significantly quicker for me.

    recent (and yes, often dynamic) languages abstract more from a development perspective, and while this does not come without cost it does allow for improvements in productivity.

    does this mean that quick and dirty jobs cannot be done in things like C++ or Java? absolutely not. just that in my experience it’s far easier to do what Ryan describes above as disposable applications in something else. that’s also what i hear from a significant majority of the developers i speak with.

    in other words, while i would never make the argument that language dictates life expectancy or longevity with high precision, neither do i think they’re unrelated.

    to christopher’s question, here’s a different way of answering it that might be clearer. in an enterprise of a more recent vintage than the example i cited in the original entry, it’s likely that the EDI, inventory and other applications would be written in Java and housed within an application server of some sort. it’s equally likely that the local application with a GUI and a database would either be written in VB.NET (the one i actually built was actually an Access DB with some fancy macros, i’m ashamed to admit) or built as an online application (b/c availability is better today than it was at the time) using PHP, Ruby or something similar.

    now could this ‘enterprise’ have built the local application in Java, and the EDI, etc apps in .NET or PHP/Python/Ruby? certainly.

    but i’d contend that those use cases would be more atypical than not. and productivity – i.e. the time it takes me to churn out the local application in Java vs an alternative would be a factor. tooling might mitigate that to a certain extent, as the success of VB proved, but not completely.

    does that answer the question better?

  6. Stephen,
    I’m in no position to comment on which language when, but I do worry about applications that are built with a “temp” mindset. once the app is built, it is the user that tends to determine how long the app lives for. Many Y2K arose because the developers thought that the app would die long before that became an issue. They were wrong.

    We need less quick and dirty, and more quick and clean. Terms like extreme programming terrify me, but then maybe that is because Im just an enterprisey user…

    Now that i have commented, I suppose I should listen to the podcast….!)

  7. I wrote a “short term” PHP3 app to monitor whenever SSL connectivity over HTTPS went down on a particular server at a rather large mfg company… that was well over 6 years ago. It was setup to send me an email whenever it went down. I’m still getting emails every now and then 🙂 They’ve extending the app b/c the liked it so much but have never removed the hard coding of my email address (originally in case SQL connectivity went down). They even added in SNMP features… but plenty of my original code is still there.

    What I think doesn’t fit with your argument are the Yahoo, Google, (insert big Fortune X company I’m not allowed to name) etc that actually built “enterprise applications” on PHP, Python, etc. I don’t think Yahoo Finance is “disposable software” for Yahoo. Often components are disposable, but the application is not. Which gets me to my particular thought after reading your post – is it that the software is disposable or just that the componentized architecture of PHP, Python, Ruby, heck open source applications lends better to “disposability” – even with the simples, small apps. I think it’s not the language that makes the software disposable, but rather the design/architecture that is commonly used when building “scripting applications” builds in disposability… that’s why my PHP3 app is still in use today (prob updated to PHP4 by now) – pieces of it were easily disposable/upgradeable – even though the software application as a whole is just as important today as it was 6 yrs ago.

  8. > What I think doesn’t fit with your argument are the Yahoo, Google, (insert big Fortune X company I’m not allowed to name) etc that actually built “enterprise applications” on PHP, Python, etc.

    Stephen’s argument isn’t reflexive. PHP is good for disposable software AND enterprise software, but Java is only good for enterprise software.

    > We need less quick and dirty, and more quick and clean.

    I love that.

    The problem with disposable software is it isn’t disposed soon enough.

  9. i think it’s clear that i’ve created a scope problem. my bad entirely. great discussion, but i think we’re all on different pages. i’ll follow up on this one soon(ish).

    in the meantime, a couple of answers to comments.

    Mike: “I think it’s not the language that makes the software disposable, but rather the design/architecture that is commonly used when building ‘scripting applications’ builds in disposability”

    i think that’s mostly true, but i do think language has something to do with it. if we think of languages as a spectrum, and using for the sake of argument abstraction as a means of judging them, there is a clear progression. c is more abstract that assembler, java is more abstract than c, php/ruby/VB/etc are more abstract than java. as such, i do think there are indeed differences in a languages suitability to creating disposable applications. as an extreme example, i can tell you that the odds of me creating a one off app in assembler are pretty much zero (not that i could any more anyway).

    Christopher: “Stephen’s argument isn’t reflexive. PHP is good for disposable software AND enterprise software, but Java is only good for enterprise software.”

    i don’t know that i’d be that hard and fast about it – i’ve been on projects where Java apps were cranked out to solve a particular need – but you’re correct. that’s more or less what i’m saying.

    “> We need less quick and dirty, and more quick and clean.

    I love that.”

    i agree. it’s one of the reasons that i find some of the new web frameworks so intriguing. not because they’re the solution to all problems, but rather because they are not. instead, they take a narrow spectrum of application types and make the development of a solution quick and (mostly) clean.

    “The problem with disposable software is it isn’t disposed soon enough.”

    partially agree. i’d merely add that in my experience, disposable software is often the result of earlier mistakes in design and execution. otherwise, i agree.

Leave a Reply

Your email address will not be published. Required fields are marked *