Enterprise Sour Grapes

Recently a post by James McGovern on Why Ruby Isn't Enterprise Ready floated my way. I felt it necessary to offer up a response. My disclaimers: I am not familiar with McGovern's past work, I am not (yet) using Ruby in the "enterprise", and I am far from a Ruby or Rails expert. I am, however, trying to bring Ruby the capabilities of Enterprise Java using JRuby, and I've done a bit of Enterprise work during my ten years as a Java developer.

Point-by-Point Responses

McGovern's points are not all bad, but most of them are either poorly realized or amount to chicken-and-egg arguments: Ruby isn't in the enterprise now, so it's not ready for the enterprise. I'll try to blaze through the nonsense and tackle the substantive issues more directly.

Point 1: Books for Ruby Suck and are too introductory
Nonsense. Ruby as we know it today is young and has only garnered attention over the past few years. Books are written to be sold, and since almost everyone doing Ruby work has started very recently, the market for introductory books is largest. There are, however, more and more people interested in enterprise Ruby, and so the books are starting to follow. It will take time, just as it did for Java, but it doesn't mean Ruby isn't ready to make the jump to "enterprise" software.

Point 2: Huh? (i.e. poorly-written nonsense)
I couldn't really glean out any specific point being made here. I'm not familiar with "insulting" firms, though perhaps that's a crude attempt at humor. Assuming he means "consulting" firms, he's only partially right; obviously if an organization already has an "enterprise" plan, they won't be told how to rewrite it. However, any consulting firm worth its mettle will try to follow the same best practices when building out a new architecture or conforming to an existing one, and those practices aren't specific to any language or platform. This has nothing to do with Ruby.

Point 3: Ruby isn't enterprise ready because consulting firms aren't doing it
Nonsense. Consulting firms have a vested interest in keeping their technology portfolio tailored to the demands of clients. They also have an interest in telling clients what they actually want, so those demands continue to fit their portfolio--just like Enterprise Thought Leaders have a vested interest in convincing others their platform of choice is the best solution. Regardless, Java has a huge presence in the enterprise space, and has become the perfect vehicle for consulting...a well-understood, boring, accepted platform. .NET is well on its way to "boring" as well. Ruby will have work to do to "break into" this world, but its absence there says nothing about its viability as an enterprise platform. It's a small fish in a big pond...but fish grow.

Point 4: Magazines read by enterprise architects don't cover Ruby
Nonsense. This doesn't even make sense, since I doubt McGovern can speak for all "enterprise architects". If he means "enterprise architects that only use Java or .NET or don't read about languages", then he may be right. Otherwise he's making a blanket statement that's obviously impossible to prove and is at best totally wrong.

Point 5: Fortune 500 company-employed architects don't blog about Ruby
If this is true, then they are at risk of being passed up by others that do read and blog about Ruby. However this is another statement that says nothing about Ruby's enterprise capability. It only continues to say that "Ruby isn't enterprise now, so it's not ready for the enterprise."

Point 6: Large enterprises like big vendors (i.e. the same old Open Source FUD)
Ruby is garnering more and more attention from the "big vendors", but they're naturally cautious about leaping into a new language that may or may not be the right way to go. However, this argument could have been said for languages like Python, which now sees extensive use in enterprise apps and for which Microsoft has been funding IronPython for their CLR. Ruby is simply a tool; the eventual platform we will use to build enterprise applications is being built and will be built upon that tool, and it will in many cases be "big vendor"-driven.

Point 7: Big vendors can't make money off Ruby
Sun does not make a lot of money off Java, if they make any at all. Microsoft does not make a lot of money off the .NET languages. In either case, what little income they gain is offset by the massive research and development staff making those platforms possible. They make their money by selling products related to those platforms, such as toolsets and server software and hardware. Nobody is making money "selling Java" or "selling C#", just like nobody makes money "selling C" or "selling Ruby". As in the real world, the market for tools pales in comparison to the products of using and deploying those tools effectively. And again, this says nothing about Ruby's technical merits.

Point 8: Legal transparency is more important than software development productivity
This has nothing to do with Ruby or anything else, except to say that "so what if there's productivity gains to be made...I'm too busy dealing with the lawyers". Certainly, the cost of answering a subpoena may offset productivity gains elsewhere in an organization. However, McGovern does nothing to demonstrate any causal relationship between the two. I'm not entirely sure that he's demonstrated anything at all.

Point 9: People, then process, then tools
If tools matter least of all, then whether the tool is Ruby or some other language is entirely irrelevant. This point basically states that all his other concerns about Ruby in the enterprise are moot. Huzzah!

Point 10: Do not talk about Fight Club.
There is no point 10 in McGovern's post. I'm not sure if this is intentional or due to carelessness but judging by the rest of the post I'd expect the latter.

Point 11: More ranting about productivity
The absurd productivity gains claimed by some in the Ruby community are a concern, but these same sorts of numbers have been used for every Next Big Thing. Undoubtedly, Ruby will have an effect on productivity, and I believe it will have a strong positive effect, but this point has nothing to do with Ruby in specific.

Point 12: More ranting about books
Complaints about a particular magazine's method of giving out "awards" or publisher's use of those "awards" to market books has nothing to do with Ruby. There's plenty of SD Magazine "award-winning" books in the Java and .NET worlds too.

Point 13: Productivity gains are outweighed by increased contract negotiation time
Clients are interested in getting the best value for their dollar, but are also interested in tried-and-true technologies. As mentioned earlier, Ruby is still young, but its youth says nothing about its capability in the enterprise. I remember plenty of companies that shunned Java early on for the same reasons...if I'd followed their advice I'd be looking for COM+ and Microsoft DNA work. It's just another chicken-and-egg argument that has affected every other language and platform since there have been such things.

Point 14: Agile methodologies should emphasize code generation and the agile community doesn't get it
Other than a brief mention of Ruby, this doesn't seem to have anything to do with the core thrust of his post. It's worth mentioning that the poster child for Agile development, Rails, generates a large amount of its code before and during deployment.

Why Respond to such Drivel?

I've heard many folks ask this question about responses to such misguided "thought leaders" as Mcgovern. Why respond to nonsense? Why give air to FUD?

There's probably a few good answers.

First off, not responding implies to many that there are no counterpoints to be argued. Responding to a well-written and well-thought-out post is probably less important than responding to FUD, since the latter is generally filled with lies and vitriol. This is the case with McGovern's post; the points are not valid and generally say nothing about Ruby, but the title and thrust of the posting implies such. Other "enterprise architects" that skim through such a posting may use it to solidify their own prejudice and bias toward specific tools and platforms, which only hurts the evolution of software and software development. It is for this reason that I choose to respond and choose to publicly call out such bogus claims as well as I am able.

Second, such posting make us folks actively working on Enterprise Ruby more than a little pissed off, because the content is so weak and the facts are so twisted. Consider this post my outlet for such frustration. Edmund Burke said it best: "The only thing necessary for the triumph [of evil] is for good men to do nothing." Perhaps McGovern is not evil, and perhaps I am not good, but I will not stand by and do nothing. If roles are in actuality reversed, I would expect the same from McGovern.

Third, we like to talk. This is certainly true, but does not necessary imply any malice. I like to write...so sue me.