Why I think you have to consider Ruby on Rails
The whole debate that I had the other day about .NET developers learning Ruby on Rails stemmed from an earlier conversation about how much more productive you can be in Ruby on Rails vs. Java or .NET. Based on what I keep hearing, I think it’s really hard to ignore Ruby on Rails.
Just to be clear, I have learned Ruby on Rails by playing around with it on side projects, but I haven’t done any big real world apps in it yet. But I have too much evidence in favor of Ruby on Rails.
- People I respect telling me that they estimate that they get things done 4x faster in Ruby on Rails.
- Numerous blog posts (which unfortunately I didn’t bookmark) of .NET devs who took the plunge, decided to do a project in Ruby on Rails instead of .NET, and finished earlier than they would’ve with .NET, even with the learning curve of learning something new.
- A large company had a team that wanted to use RoR for a project, but the company is largely a Java shop and told them no. The team went and did it anyway and 4 months later they were done. The higher-ups were mad and sat down and estimated how long it would take to rewrite it in Java and estimated it at 18 months.
If I were hearing this from just a couple people, I could discount it as fanboyism, exaggeration, or whatever. But I’m hearing too much of this sort of thing.
Just imagine if you could cut the cost of software development to 25% of its current cost. Think of how much money your IT department can save. Think of how much more you could accomplish each year.
Sadly, it seems that very few companies are adopting Ruby on Rails. Maybe they aren’t hearing these anecdotes, or maybe they’re dismissing it as fanboyism and exaggeration. Or maybe they feel that their current IT staff wouldn’t be capable of succeeding or that they won’t want to learn a new language and a new way of doing things.
If we were talking about a slight improvement in productivity, you could easily say that you’re sticking with .NET or Java or whatever because that’s what your team knows well, and I might say that you have a valid argument. But a 4x productivity gain? How can you ignore that? Even if my numbers are exaggerated and it’s only a 2x productivity gain, how could you ignore that?
I hope that IT departments really get serious about this, because a company could have a huge advantage if they were able to complete 4x the work each year. Personally, I really hope to use Ruby on Rails sometime myself because I want to do things this fast. I remember when I first started doing ASP.NET MVC and I cut my usual estimates in half and how awesome that felt. If there is a better and faster way to do something, then count me in.
The problem is, they won’t do the same work, they’ll just demand 4x the workload. So yeah its “cheaper” to do the same thing, but you are only doing that because its what cost 100 people for 52 weeks to do. They aren’t interested in spending extra cycles on the craftsmanship and testing required to achieve 4x, they just hear 4x and do what they do now, fill the box with work.
Yeah, but I think if you do Ruby, you’re going to have to test, otherwise it won’t go so well. The 4x productivity gain comes with a caveat, that you will have to test. Otherwise you will have a new problem (lots of bugs).
Given your salary as an IT staff employee is a sunk cost. They committed to it. Can you provide more value to offset your cost, by using rails? Or actually testing? Or would the best value be, not building anything because only the IT manager asked for this tyrade of a project.
Hello Jon!
I too hear these sorts of anecdotes on a regular basis, but I must admit bias as I’ve also experienced them personally and through the success of many of my company’s customers.
Many large companies are beginning to adopt Ruby on Rails. Some are trialing it formally, many others have “rogue” groups trying to get things done, and others have picked up Rails through acquisitions.
It takes time for things to happen, but it IS happening. Perhaps one of the biggest roadblocks is the old proverb: If it’s too good to be true, it’s probably not true!
Both fortunately and unfortunately for Rails, it is that good, and it is true. :-)
Thanks for reaffirming my assumptions! I’m surprise at how people will dismiss a technology just because so many people love it. Shouldn’t that be a good thing?
I think it goes without saying that convincing a company that hasn’t bought into automated testing or quality construction AT ALL that Ruby [on Rails] is a good idea will be tough. That company isn’t interested in making rational, objective decisions about technology. Subjective, risk(read: fear)-based decisions reign supreme in that company.
It’s not entirely helpless, but it will be an uphill battle. I haven’t been around long enough to attest to this first-hand, but I’d imagine this was the cycle with many new tech stacks. Surely people scoffed at .NET as an untested upstart that had no place in a Java-dominated industry. And before that, people surely dismissed Java as an inefficient toy that had no place in the serious C/C++ dominated industry.
Times change, and those type of companies are always the last ones to jump on the bandwagon. I love that anecdote about a team that went rogue and did a project in RoR in 4 months that would take 18 in Java. To me, that’s an amazing testament to the power of that framework, and it should be the evidence needed to drive change. In reality, the chances that it drove change vs. the developers got reprimanded/fired is depressingly close to 50/50.
So what am I trying to say? I think you shouldn’t be as dismissive of Ruby [on Rails] as those companies you loathe for their inaction. Try it out at home, or start using it in parallel for internal tasks (build with Rake, test with IronRuby and Cucumber/RSpec, etc). Then, as the saying goes, “change your company, or change your company.”
I wonder, does this really mean that Rails is faster; or does it mean we’re doing .NET the wrong way?
You mentioned yourself an example in which a factor of 2 improvement was achieved in the .NET environment – when transitioning to ASP.NET MVC. So there you have seen a 2x improvement without changing platform. With hindsight, we can say that the old way of doing things was slow (at least, for the kinds of projects that you were working on).
This raises two questions:
– how do we know that ASP.NET MVC is “as good as it gets” (i.e. that we cannot get even faster in .NET)? (Are we even trying to do so? What would it mean to try, to look for such opportunities?)
– secondly, these people who say Rails is 4x faster: what are they comparing it to? The new ways of doing things in .NET, the old ways, or old ways of doing things in Java (which anecdotally may be even slower still)?
In summary, I’m suggesting that the comparison should be a driver to further improved the .NET platform, not (only) a driver to consider Rails.
@John,
Great points. It’s obviously a much easier step to get WebForms developers onto ASP.NET MVC than it is to get them onto Ruby on Rails, so that’s probably a more realistic step for most teams.