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

By: Josh Charles

Josh Charles — Tue, 26 Feb 2008 14:15:34 +0000

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.

By: Copolo

Copolo — Mon, 25 Feb 2008 21:22:22 +0000

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.

By: Ned Batchelder

Ned Batchelder — Mon, 25 Feb 2008 00:58:28 +0000

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.

By: Craig

Craig — Mon, 18 Feb 2008 20:10:02 +0000

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.

By: pinderkent

pinderkent — Mon, 18 Feb 2008 18:03:39 +0000

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.”

By: Craig

Craig — Mon, 18 Feb 2008 16:01:30 +0000

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.