Thought I’d throw in my 2 cents
on the ongoing Ruby Enterprise debate stirred up by James
McGovern. My main point
– this isn’t about technology but is about how technology is adopted.
However, since a couple of technology arguments are being used as a smokescreen
let’s dispense with them. First, the argument that there aren’t
any Enterprise applications written in dynamic languages so clearly dynamic languages
are not up to the task. Not true. For an experiment, call up your local electric
utility (as a good example Duke energy) and ask them what they use
to to design and maintain their electrical network. Odds are that it’s
Smallworld –
written in a dynamic language called Magik, similar to Ruby. These are large, expensive
mission-critical applications that drove Smallworld’s growth until it went public
on Nasdaq in the late 90’s and was later acquired by GE (trust me, you can’t get
any more Enterprise than GE). Of course I’m writing about the domain I know
best, undoubtedly there are many other examples.
Second, let’s address the argument that productivity gains from dynamic languages
are immaterial since they only provide benefit in the up front costs of developing
applications. I agree the up front costs of application development are small compared
to the full life-time costs of an application. However, that misses the point that
the same productivity gains also hold true
for applications in maintenance mode. And it also misses another point – how
many Enterprise applications reach maintenance mode these days. They constantly
need to adapt to changing business requirements (James brings up transparency as
a present day issue) – an area where dynamic languages shine. The productivity
argument is a valid one. If it wasn’t why would anyone in their right mind use
dynamic languages in the first place?
So, let’s move onto what I see as the the crux of the issue. Its not about
technology but instead about how large organizations adopt technology.
If you put yourself in the shoes of a large company, why on Earth would you want
to throw away the investment that’s been made in Java (or C++ or Oracle or SAP
or whatever) to start with something new? It just doesn’t make sense, the costs
of rewriting applications are enormous (and it will fail anyway) not to mention
the training costs for developers/testers/documenters/user experience designers/etc.
Its something you should never do.
New technologies only come into play with new development
projects, which are few and far between in the average company. To
expect Ruby to be showing up in Enterprise application development today isn’t
reasonable – let’s ask the question again in a few years. For comparison, remember
the first time you saw Java? Its was used to make glacially downloading
applets that were more annoying then helpful. That puts us in the 1996/97 time
frame. J2EE wasn’t released until
December 1999. And of course there were arguments about how it wouldn’t scale,
the toolsets weren’t mature, etc. History repeats itself.
Yet, with once crucial difference. Sun played a very active role in pushing Java.
Now its the open source community that pushes new technologies (you could argue
that large corporations fund open source projects as competive weapons to push
their technology agendas, but let’s leave that for now). As Stephen O’Grady perceptively
notes:
The point of all of this … to me signals an important shift in the
way the technology industry assimilates new technologies. When barriers to entry
were high, it was far more true that some combination of analyst/CIO/vendor conspired
to set the technical agenda and direction within large enterprises. Developers,
lacking budget, were more or less at the mercy of the folks running the show
– dependent on them for tools, databases and so on. And in many cases, as James
points out, that’s still the case. But with the barriers to entry to many important
infrastructure pieces – app server, database, web server, development tool –
going to zero, the power has shifted subtlety but importantly. Many larger analyst
firms haven’t yet quite digested the fact that the real power now – as evidenced
by the success of Linux – is returning to the hands of the implementers themselves.
Analysts might still be helping set the direction within enterprises these days,
but it’s the direction that developers that have set for the analysts.
So come back in a few years and ask the question again. I bet you I know the answer
already.