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.