Ruby on Rails Sucks!

At my slave software engineer job, I'm working on a web development project. Currently, it's written in jsp/Java/Spring/Beans, which is horrible, but at least it runs. Rewriting it in another language probably was a good idea.

My boss decided to rewrite it in Ruby on Rails. Neither my boss nor anyone else here has ever used Rails before. In other words, a critical business decision was made solely based on hype.

I looked around the Internet for information about Ruby on Rails. Most webpages fall into two categories. First, there are rants that say "Rails sucks!" Second, there are rants that say "Rails is awesome!" However, there were no webpages with details about how Rails actually works. This was a bad sign.

Some people say "If you want to know the latest developments in Rails, you have to follow Rails blogs and read the Rails online discussion forums." I have to subscribe to a bunch of blogs and sort through old posts, just to know how the language works? How about some documentation?

If I need information on Perl, C#/ASP.NET, php, or Java, there are plenty of online resources. For Rails, there's practically nothing. If Rails is so awesome, then why isn't there any documentation?

Converting a preexisting application to Rails is not easy. Rails insists that you use a specific naming convention. Your primary key must be auto-increment integer. Table names must be plural (i.e. turds). Join fields must be singular (i.e. turd_id). In that case, the turd_id field will automatically join to the turds table for you. You can override this behavior, but it isn't worth the hassle. They decided to completely redo the database. Some tables were definitely not compatible. For example, Rails won't support a table where the primary key is two columns.

Rails generates a lot of scaffolding for you. That is nice. However, when you have to put in your actual application logic, it's just as much work as any other language. If what you want is exactly covered by the auto-generated templates, then Rails development is very fast. If you need something different, then there's not as much gain.

Rails is interpreted and not compiled. You won't discover your mistyped variable name or function name until you actually run your code. You can compensate for this by automated unit testing, but you can test via script in any language.

You can have polymorphic tables and polymorphic fields. In most circumstances, these features are unnecessary. If a language has a cool feature, then we'd better use it in our application! (This is a management mistake and not a specific defect with Rails.)

Rails encourages you to normalize your data. You can go overboard. It may seem cool to split one table into 5-10 smaller tables. Each extra table is an extra few hours of coding and testing. It's an extra database query every time you load your page.

Instead of making "stock symbol" a varchar(8) like a normal person, my boss split this up into several sub-tables. He normalized out symbol. He made it polymorphic for stocks, options, and futures. He added a provision for foreign-listed stocks and ADRs. He normalized "exchange" out to a separate table. Add this philosophy over the entire application, and you have one big cluster****. (Over-normalizing your data is a management mistake and not a Rails mistake. However, Rails' model encourages such behavior.) It may seem cool to be using a whole bunch of "belongs_to", "has_one", "has_many", and "has_and_belongs_to_many", but after awhile you say "Why are there all these joins?" In order to get any useful information, I have to join 5-10 tables?

We have to totally reorganize our database before importing to Rails. However, we cannot abandon the old system immediately. This means that we have to rewrite the old system for the new database design and then start switching to Rails. Some features of the old system cannot be rewritten in Ruby/Rails, because of Java-specific libraries we're using.

It may seem neat to have ActiveRecord automatically write your queries for you. Actually writing out a few lines of SQL isn't a hardship. Even though ActiveRecord is writing the SQL for you, there's still the overhead for the database calls. Even though ActiveRecord does a bunch of stuff for you, you still have to program in your application logic at some point.

My boss said "We're not wasting money on Microsoft software licenses! We're not feeding the Microsoft monster!" However, because none of us know Rails, they had to hire a Rails consultant (and he's probably getting paid more than me). Even though we saved the cost of Microsoft licenses, there's the wasted time and the cost of the consultant. For a Microsoft solution, I could easily learn it on my own. I can't learn Rails on my own, because it's totally undocumented.

I feel dirty recommending Microsoft over an open source solution, but Rails is horrible. At least with Microsoft, you get something that's well documented and stable. A Microsoft license costs money, but wasting time also costs money. There are other open source possibilities, such as php, which also seem better than Rails.

They needed something done quickly, so I got permission to do it in php instead of Rails. It felt weird looking up the php tutorial and API, and getting a useful answer. Writing out your SQL queries and reading the fields out of the result set isn't the huge burden that Rails makes you imagine. Compare that php tutorial to anything available for Rails. The php tutorial is complete, and the Rails tutorials are sorely lacking details.

My boss said "Rails is a rapidly evolving platform! Isn't that exciting?" If I'm investing in a business, I'd prefer to use a stable platform with slightly fewer features. My employer doesn't need something super wicked cool. My employer needs something that runs. You read from the database, manipulate the data, display it on the page, get input from the user, and write back to the database. It's not rocket science. It's a boring data manipulation job.

Having Rails on your resume is a cool item. If I could honestly write "2 years Rails experience", then I'd have many job offers. However, two years from now, something else will be trendy. At that time, employers will be demanding "4 years Rails experience" or something else. Besides, do I really want to work for someone dumb enough to write their application in Rails?

At this point, my boss is emotionally attached to the decision to use Rails. They can't say "Whoops! Maybe that was a mistake!" Maintaining the fantasy requires ignoring feedback, which further increases the likelihood of disaster. There were two big mistakes. Using Rails was a mistake. Choosing a stupid database design and rollout strategy compounded the error.

I'm also getting better at reading body language. At this point, my boss' body language is screaming "I'm in over my head and this is going to be a disaster!" I can judge the doomed nature of the project just from my boss' attitude. For example, another developer complained that the database was over-normalized, and was ignored.

My boss actually seemed reasonable before. I wonder if being in a position of abusable power has a lobotomizing effect?

I've been involved with enough disasters to recognize the stench of failure. I just work there, so why should I care? On the other hand, I'm usually the guy who gets scapegoated for the disaster. Maybe Rails will work, but it looks like a disaster in progress.