Ruby vs. the enterprise

The whole “what does it mean to be ‘enterprise’?” brouhaha (see posts from Dare Obasanjo and David Heinemeier Hansson) over James McGovern’s post “More Thoughts on Ruby and Why it isn’t enterprise ready!” grabbed my attention for a few reasons:

1. I used to write for an enterprise IT magazine, InfoWorld
2. I was also CTO and had real day-to-day responsibilities, so I couldn’t get away with too much b.s. I had to live with what I wrote in a real environment and therefore couldn’t coast along on pure pontification.
3. The combination of my roles in #1 and #2 led me to believe that quite often, the use of the term “enterprise” alongside many product names was a label used to part fools from their money.

My feelings on the matter are pretty well summed-up by a feature story I wrote for InfoWorld in 2004, “Top 20 IT Mistakes to Avoid.” I described the problem with the “enterprise” label in mistake number 20: “being a slave to vendor marketing strategies”:

When it comes to network devices, databases, servers, and many other IT products, terms such as “enterprise” and “workgroup” are bandied about to distinguish products, but often those terms mean little when it comes to performance characteristics.

Quite often a product labeled as a “workgroup” product has more than enough capacity for enterprise use. The low cost of commodity hardware — particularly when it comes to Intel-based servers — means that clustering arrays of cheap, workgroup hardware into an enterprise configuration is often more redundant and scalable than buying more expensive enterprise servers, especially when it comes to Web apps.

I didn’t write about programming languages back then, but the same principles apply. In my opinion, choice of programming language has almost nothing to do with being “enterprise ready” or not. Take a tour through any “enterprise” shop, and you are likely to find at least a few ill-conceived Visual Basic or Lotus Notes apps (both on legitimate “enterprise” platforms!) quite literally holding back the business, just begging to be replaced by a well-designed web-based app built on Ruby on Rails or PHP. I’ll take a well-designed RoR or PHP app over VB or Lotus Notes any day.

But let’s be fair. As RoR and PHP grow increasingly popular in enterprise settings, expect some really poorly-designed RoR and PHP apps to stink up the “enterprise” joint. As Frederick Brooks noted twenty years ago in his famous essay on software, there is no silver bullet. So, RoR, Java, PHP. . . whatever. Just find me some talented programmers and we’ll figure it out (ok, the Lotus Notes and VB guys would be kicked aside quickly, but you know what I mean).

Unfortunately, despite the beating he is taking in the blogosphere, I think James is probably just providing a realistic (if somewhat cynical) view into how lots of “enterprise” IT decision-making happens: lots of vendor FUD being fed to timid IT staffers who outsource their strategic thinking to Gartner/Forrester/etc. It’s not a pretty picture.