Others are leaving Ruby on Rails, as well. And it’s not going well.

Several months back, there was somewhat of an uproar in the Ruby and Ruby on Rails communities when it was revealed that after two years of effort, the CD Baby Web site was abandoning their Ruby on Rails rewrite. The CD Baby site was reimplemented in mere months after returning to the use of PHP. This past week, I have been working with another company that is in a very similar situation.

In this company’s case, they had a number of legacy, in-house systems developed in C and COBOL that were eventually moved to Web applications written in Java in the late 1990s. By early 2006, their Java-based software systems were starting to show their age, and it was decided that they would start rewriting many of them using Ruby on Rails. After an initial analysis and design period, the implementation began, with the greatest portion of the work being completed by August of 2007. The rollout was complete by the beginning of last September.

There has been an endless stream of complaints from the users of the software since that time. I’ve read through six 3″ binders full of complaint reports. Now, the software itself isn’t poorly implemented. It’s actually among some of the better corporate Ruby on Rails code that I’ve seen over the past few years. Design-wise, it’s actually pretty decent, too. From the complaint reports I’ve read, most of the users are also happy with the performance of the system. It’s just that the applications themselves cannot be used well in a productive manner.

After talking to a number of the developers who were involved with that project, I heard repeatedly that Ruby on Rails was too restrictive in a variety of ways. The developers had to developer towards what Ruby on Rails would effectively let them develop, rather than developing the software to meet the needs of the users. The management had decided on a Ruby on Rails-or-nothing approach, so using alternative technologies in such situations was unfortunately not an option.

At this point, the company is trying to return to their Java-based systems, which worked better than their Ruby on Rails implementation. This will not be an easy task for us. Their data model changed in many ways, to name one major stumbling block. It’s not been decided yet whether they’ll update their Java code to handle the new model, or transition their new data back to the previous databases. Regardless, that aspect of the transition alone will be difficult. Updates to the Java code to handle the new capabilities introduced to the Ruby on Rails system since its deployment will also be required. There has been some consideration of a hybrid approach, with some of each system being used, but some of the stakeholders feel this will only cause more problems.

A lesson we can take from this, beyond the obvious ones, is that when performing a large-scale rollout of a new system, it’s important to be able to revert back to the existing system nearly immediately. Not only that, but it should be possible to do this several months after the new system is initially rolled out. Although it will incur an extra cost of doing business to maintain the old, albeit unused, software for some time, not having it available to roll back to could be tremendously more costly.

You can skip to the end and leave a response. Pinging is currently not allowed.

2 Responses to “Others are leaving Ruby on Rails, as well. And it’s not going well.”

  1. Nathan says:

    Yeah, I’ve seen Ruby on Rails abandoned at a few places because Rails dictates to rigidly (which is quite funny considering Ruby itself is to flexible). My personal pet peeve has always been ActiveRecord. Compare AR to Grails’ GORM – GORM has all the benefits of AR, but provides a waste number of options to even cater for legacy databases – something AR specifically does not cater to.

    I don\’t mean to plug my own blog, but this is exactly the sort of thing I was talking about in my “Productive vs. Effective” article here: http://nathan.crause.name/entries/programming/productive-vs-effective

    You can produce Rails stuff quickly, but a lot of times the end result simply doesn’t cut the mustard. While some level-headed Rubyists will point out that Rails was intended for X, Y and Z, the problem is that the vast Rails community keeps trying to sell it as the Alpha-and-Omega of web-development.

    There\’s bound to be more stories like this, I’m afraid.

  2. You can produce Rails stuff quickly, but a lot of times the end result simply doesn’t cut the mustard. While some level-headed Rubyists will point out that Rails was intended for X, Y and Z, the problem is that the vast Rails community keeps trying to sell it as the Alpha-and-Omega of web-development.

Leave a Reply

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Click to hear an audio file of the anti-spam word