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.
February 18th, 2008 at 5:01 pm
It seems the real lesson here is to understand the actual needs of your users. That might result in building software they can actually use, and will use. It’s a language independent issue. Doing a poor job of requirements gathering, analysis, and design will render the best written code meaningless. Here it seems that the RoR hype was allowed to override good management, good software engineering practice, and frankly, good common sense. I’ve seen this scenario play out many times at many companies over the past twenty years. You’ve cast Ruby on Rails as the evil doer here, but it’s not the problem. Any shiny new object could have filled the RoR role in this story. What you’ve missed is pointing out a learning opportunity for software engineers developers and managers. That lesson is to focus on the needs of your users, not the style of the hammer you are wielding.
February 18th, 2008 at 7:03 pm
Craig: No, the technical nature of Ruby on Rails was also to blame, as per my discussion with the developers. Please note the following paragraph of the article:
”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.”
February 18th, 2008 at 9:10 pm
No, Ruby was not to blame. Technical management and developers who did a poor job of requirements gathering and analysis are to blame. It’s a poor workman who blames his tools. Declaring Lanquage X and Framework Y as the implementation tools for Problem Z, prior to understanding what Problem Z is, and what kind of solution makes sense, leads to exactly this situation. It is easy to look back and say, “If we had used FORTRAN IV, we would have been successful”. It’s clear from your scenario that problems with using RoR for this particular situation was not working, yet they went forward anyway. This was a failure of leadership.
February 25th, 2008 at 1:58 am
It seems that Ruby on Rails is experiencing a bit of a backlash. This article would be much more convincing if you could provide some specific instances where Rails’ limitations prevented the developers from building an app their users could use. It’s hard to imagine how the structure of the framework literally prevented them from meeting their users’ needs.
I’m not saying Rails is the perfect framework; I’ve never even used it. Maybe it is fatally flawed, I don’t know. You haven’t done anything to illuminate its limitations, you’ve simply passed on the gossip that there are some.
February 25th, 2008 at 10:22 pm
It’s been my experience that frameworks or languages that perform “too much magic” - apparently one of the design goals of RoR - can be very limiting when you are implementing a well-designed system that is something more than a basic CRUD application.
I’ve seen some impressive things developed in Ruby on Rails, but I don’t think it’s an appropriate choice for the corporate level - or for software companies with more traditional processes.
RoR should be used for what it was made - quickly and rapidly developing small web applications; and should not be used for developing large, complex systems which have had a lot of underlying planning and thought put into them.
February 26th, 2008 at 3:15 pm
Copolo,
I don’t know what you mean exactly by large, complex systems. I’m current implementing a RoR application that is much more involved than a ‘basic CRUD application.’
The organizational structure of RoR makes it very easy to work with and extend as needed. Need to validate against an Microsoft Active Directory? Great, write a plugin. Need to run through a queue of processes every night at 3 a.m.? Easy, write a plugin. Need to generate images? Don’t even need a plugin for that.
RoR makes doing the web parts of your application superbly easy - better than any other framework I’ve come across. But that’s mostly just interface, right? Well, for all that ‘other stuff’ you need to do, Rails helps you keep it organized.
It’s only called ‘magic’ because you don’t understand what’s going on. Take some time to learn what’s underneath, and then you’ll be going places.