UPDATE: one astute reddit commenter pointed out that I only included the strawman arguments of the Java/.NET crowd. So I’ve updated the Rubyist’s rantings.

The old “enterprise software” debate has sprung up again. We have been willing participants in the cross-border sniping in the past, we admit. But this time around, we think we’ll play a different part: translator.

So the argument generally goes:

“You can’t use Ruby for enterprise applications. It doesn’t scale, nobody understands it, and it is slow. Oh, and there is no ecosystem around it. And, it is only 10 years old. And open source. With no big vendor behind it. And no SLAs. And, ummmmmm, we haven’t seen the first spectacular failure yet, which means all Ruby apps will be failures.”

“That’s horse puckey. Ruby is perfect for the enterprise, because it is fast, light, flexible, easy to learn, provides very powerful tools, and is very productive. Java and .NET are too big, too complex. That threading stuff is hard. Nobody understands even one percent of the libraries. Neither one is open source. And you Java/.NET people are mindless drones. With goo for brains.”

Here’s the problem. They aren’t talking about the same thing. It comes down to definitions. The first people are talking about enterprise-class software. The second people are talking about the software that runs the enterprise. And rarely, if ever, are they the same thing.

Enterprise-class software are those behemoths that everybody thinks of when they envision how Big Companies work. They process 10 million transactions a minute, which span five different databases on three different hardware platforms. They run on an amalgamation of equipment, from rack-mounted servers to mega-switches to specialized phones. They take three years to write, and three more to get right.

The software that runs the enterprise is the internal HR web portal that lets employees discover the phone number of the benefit planner without having to call the CEO. It is the code that reaches into the 50 Word documents and Excel spreadsheets on the marketing guy’s Desktop and turns them into records in his contact manager. It is the code that scrapes Amazon for data about the products your company sells, and dumps the scraped data into a local LDAP store for analysis later. It is, in short, everything that anybody in the enterprise actually interacts with. (And it is also the topic of our forthcoming Enteprise Ruby Studio.)

For Enterprise-class software, you would be hard-pressed to find anybody to suggest that it be written in anything OTHER than Java or .NET right now. The few people you will find saying otherwise will either be pushing COBOL on the mainframe, C/C++ because they don’t believe in evolution, or are named Paul. Serious Ruby people have yet to suggest, as far as I can tell, that Ruby is the code that should be, say, running the NYSE.

For the software that runs your enterprise, though, more and more “serious people” are turning to Ruby and its agent provocateur, Rails. That’s because the software that runs the enterprise has to adapt to an infinite number of pressures placed upon it every day. From the changing whims of rotating CXOs, to the needs of newly acquired subsidiaries, to the changing nature of the hardware components that make up the physical corporation, to any number of other, rapidly-changing variables that pound upon the knowledge infrastructure of the enterprise, the software needs to adjust to keep up. And Ruby and Rails (and Python and Django and Lisp and Ocaml and whatever else) all, in their own ways, offer an alternative to the standard development path that most Java and .NET applications seem to plod down: agilely reaching completion 14 months after kickoff.

So here’s to a world where we understand what it is we’re chiding each other about. A world where we understand that there are different needs to be addressed when running The Enterprise, and that there are a wide variety of tools available to us to address them. A world where we pick the tools for the task at hand, based not on FUD, or frenzy, but on suitability. We believe, firmly and with conviction, that Ruby and Rails represent a real shift in the capability of our software platforms and development teams, and that they can mean great things for the enterprise as the glue that never sets.