(correction): fixed Upton Sinclair quote it is ’salary’ not ‘job’ (thanks for the correction)

Even with all the buzz, it is still a tough sell. If you’ve suggested Rails as an alternative to (Java|.NET) at work, you’ve probably experienced some reactionary pushback. Convincing a set of established “Enterprisy” engineers that Rails is worth paying attention to it is like convincing a Texas oil baron that he should purchase a Subcompact hybrid vehicle and become a Vegan. Why is convincing a highly paid (Java|.NET) programmer to look at Rails that difficult? I’ll steal a quote from Al Gore’s Inconvenient Truth that he, in turn, stole from Upton Sinclair:

“It is difficult to get a man to understand something when his salary depends on not understanding it.” - Upton Sinclair (1878 - 1968)

In an effort to convince, you may have sent people to some of the good Ruby on Rails blogs. This might have escalated the resistance. Asking your fellow enterprise developers to read DHH’s loudthinking.com, is like asking (the other) O’Reilly to sit down with Colbert - Mr. Enterprise isn’t going to appreciate the message because he’ll be focused on the ridicule. Rails, rightly so, is positioned as the challenger, and it makes good use of hyperbolic ridicule to gain converts. This works for most of us, but I’ve also seen it push some entrenched Java developers further away.

Common Responses

So, you are in “The Big Planning” meeting, and your boss says something like, “There is no time to finish this project, we’re going to have to tell the customer we won’t meet the deadline.” You wearily offer up the suggestion: “We might be able to deliver something on time if we used Rails to implement the web application”. And, an entire room full of Java programmers is now trying to tell you every reason from here to the North Pole why your suggestion is naïve. Here are some of the common responses:

  1. Freedom (Too Much) - “Our developers are not disciplined enough to use a scripting language.”
  2. Rigor / Formality - “Our systems are serious and require a much more rigorous approach.”
  3. Performance - Our systems need to perform, and Ruby (specifically Ruby on Rails) doesn’t perform to our standards.
  4. Flexibility (Not Enough) - (Rails) We can’t afford to follow the database standards that Rails would impose on us

Let’s take each one individually…read on…

Myth #1: Too Much Freedom

“My developers are not disciplined enough for a scripting language, we need the structure that a platform like .NET provides.”

Answer: If your developers really do lack discipline, then they should probably not be programming in something as complex as .NET. Or, Java, let’s take Java as an alternative, Java is a powerful language, but it is a language based on choice: you can create a web application using one of 30+ web frameworks, you can deal with persistence using Hibernate, iBatis, or just direct JDBC. And, if you are using the Spring Framework, you are really defining your own custom architecture as you go. If you need this level of flexibility, use Java, but, IMO, you have to be a bit more disciplined to create a good architecture in Java than you would to follow the bright lights in a Rails application.

The real answer to Myth #1: “If your developers are not very disciplined, you can’t afford to not be using a tool like Ruby on Rails. If your developers are disciplined enough to learn Struts + Spring + Hibernate + WebSphere, then I’m surprised you can’t expect them to learn ActiveRecord. Who are these people? I don’t believe you, what’s the real reason?”
>

Myth #2: Rails isn’t “Rigorous”.

Scripting languages do not provide an adequate level of “structure”.

“Our systems are serious and require a much more rigorous approach.”

Answer: Myth #2 is born of a belief that systems built-atop scripting languages can be difficult to maintain, and this Myth is closely related to Myth #1. The problem with this myth is that it has absolutely nothing to do with scripting languages and everything to do with a universal industry truth - Bad Code is Difficult to Maintain Regardless of the Language. Anyone who’s had an encounter with bad Perl code in the past is going to appeal to this myth, but the real truth is that, again, it is less a specific problem with Ruby and more a fear of the unknown. I’ve seen .NET systems designed with all the rigorous process-driven, test-first, pattern-inspired magic you will find, but they were still a quagmire of logic.

The other reason someone might offer this up is because they are frightened of not having compile-time type safety (or just frightened of not having a compiler at all). Compile-time type-safety isn’t so bad when we’re talking about the Solid Rocket Booster or a FIX gateway for the London Stock Exchange. But, with enough testing, this argument doesn’t make sense for something like a Web UI.

The real answer to Myth #2: “Right! Let’s go back to the customer and tell them that even though we could deliver something on time, we’re not going to because it’s not a rigorous technical solution and that our developers are not disciplined enough to program in Ruby on Rails. What makes Ruby less ’serious’ than Java? You guys could still draw UML diagrams of model objects to your heart’s content, and, if you really need me to, I could generate just as many gantt charts and word documents about the code we write in Ruby.”

Myth #3: Performance

“It just ain’t fast enough…”

Answer: What isn’t fast enough? Rails? Well optimize your deployment, figure out what a materialized view is. Think about the database a little bit, are you querying a table with 10 million rows? and do you know what an index is? Have you thought about database partitioning? Start using memcache, get faster hardware, use 40 instances of Mongrel. Don’t just stand there, fix it. You’d do the same for your .NET application. Myth #3 usually translates to, “I just don’t want to use Rails, and someone told me it isn’t fast enough.” In my experience Rails scales as long as you apply some brain power to your performance problems. If you just expect Rails to scale without taking any steps to achieve scaleability then you’ve really just staged a show trial for Rails. This myth is offered from people who want to Rails to break a leg out of the gate. If this is your reason, don’t tell me you didn’t have to go through a dog and pony show to optimize every other platform in your production network. Performance optimization is a black art regardless of the language or platform.

Compared to Java: From the perspective of real cost, the cost of scaling a Ruby application is on par with a similar Java application. It takes about the same hardware to scale a big J2EE application as it would take to scale a large Ruby on Rails deployment. We’re talking about a few commodity servers running Mongrel with lots of memory. IMO, it might be a lttle easier to setup Apache + mod_proxy + mongrel + Capistrano + memcached, than it is to go through the motions of installing JBoss or Tomcat and then dealing with the lack of OS integration that most Java servers suffer from. In other words, if you are creating an application and attempting to scale horizontally, you’ll probably end up paying just about the same $$ to scale a well designed Java app or a Ruby app (assuming your container is free). You may end up buying an extra one or two servers for your Ruby application, but you are going to make up the cost in development.

The real answer to Myth #3: “So, we’re not going to meet our deadline because you feel that Ruby on Rails just ‘isn’t fast enough’ in an abstract sense. You haven’t used it yet, we haven’t tested an application, or sized a real production deployment. No one has done an apples to apples comparison, all we’re going on now is your belief that Ruby doesn’t scale? Before you go on, let’s agree to at least study the issue, and the next time we talk let’s discuss specific numbers.”

Myth #4: Flexibility

“We can’t afford to follow the database naming conventions ActiveRecord demands”

Answer: You don’t have to use the ActiveRecord naming conventions. (I’ve heard this more than a few times, “we can’t use rails because of our database…”) Sure, it is marginally easier if your database tables follow the naming conventions, but let me assure you Rails can work with almost any database no matter how strange. To prove this I’ll use a Siebel database as an example. A Siebel database is definitely not designed for ActiveRecord. Every table has a MS_IDENT column which is the primary key….then every table has a ROW_ID column which happens to be the application specific identifier. Column names of the foreign keys do not match the names of the tables they references. Foreign keys don’t really reference the real primary key, they reference the application specific id which isn’t just a simple autoincrementing integer. There are hundreds of tables, and, my favorite, no define FK constraints. Did I mention that all of the table and column names are somewhat cryptic. It took a little bit of effort, a module and some before_create methods, but if I can get a Siebel database to work with Rails, you can use ActiveRecord with anything.

Compared to Java: …turn the tables on this one. EJB3 annotations in Java has the same “default naming assumption” behavior. If you don’t supply column names and table names, EJB3 will just assume them from the names of the columns and tables. If someone rules out Rails because of database naming conventions force them to hold Java (or .NET) to the same standard. Also, anyone who has been using Hibernate will tell you that Hibernate certainly has problems with oddly conceived databases - I’ve spent days trying to work with 3-way mapping tables in Hibernate only to find out that there’s some really mysterious bug with @MapKey.

The real answer to Myth#4: “You are mistaken. If you read more than the first 40-pages of the “Agile Web Development…” book, you would know this.”

Conclusion: When Reason Fails to Persuade…

Sneak it into the organization if your arguments fail. Eventually someone will notice, and there’s a good chance you’ll get in trouble. But, there’s always a chance that your transgression will go unnoticed and your boss can go on happily believing that he is using a “Real Platform”. J

But do us all a favor, if you are going to employ Rails behind hostile territory don’t turn into to one of those O’Reilly Radar-reading cool kids who is constantly throwing around references to Paul Graham and talking about how cool Web 2.0 is. Take your time, know your enemy, and work slowly. Use the language of your corporate masters

Wrong: “Ruby is a revolution, dude, it’s going to change the way you think about coding. Rails will run circles around your fancy SpringMVC or ASP.NET applications. Coding Rails is fun!”

Right: “Mr. Supervisor, sir, may I speak freely?”…..”I think we could leverage Ruby as a competitive advantage. For our next low-risk web application I propose that we engage in a feasibility study to assess the impact of a lightweight rapid application development framework. There is a real possibility that Ruby could encourage the productivity increase which will allow us to finish Q3 well under budget. It would be a great addition to our Enterprise’s ‘knowledge portfolio’.”