Chris’ recent article has stirred up quite a debate (see comments) about Rails and whether you’d have to be drunk to suggest using it. I’d like to expand a bit on Chris’ point and talk a little more about how we approach technology choices and where/why we use Rails. This article’s working title was “Why Rails (Mostly) Reigns Supreme (at Pivotal)”
Personally, I’m very suspicious of any argument that says one technology will dominate all others. It’s like saying that eventually the only tool anyone in their right mind will use is a 3/4″ socket wrench. I don’t believe this is Chris’ argument, but it was clearly taken that way.
At Pivotal we use a number of technologies, and in fact most web projects involve at least four languages. We generally use Ruby (though not always Rails, for general server-side web work, Java (Lucene, etc), extensive JS in the browser (often more lines of code than the Ruby), and C bits (Ruby C libraries, mongrel, etc) where performance matters. As well, we aggressively take advantage of Amazon’s web services (ec2, s3, and sqs). I have some knowledge of their implementations, but realistically it doesn’t matter.
The unifying theme here is Business Value. We choose technologies from our toolbox because they maximize the value we provide our clients. If Ruby/Rails doesn’t maximize business value, for example when a client already has 50 expert Java developers AND a million lines of Java invested in a “Platform”, we don’t use it.
Today a large part of Pivotal’s business (the part I’m involved in) is building web-based applications for early-stage start-ups. These companies in turn are trying to prove out novel business concepts. They don’t care about which language we use. They care about putting good software in front of users quickly so that they can make any necessary course corrections and get their business off the ground before the money runs out. This is where Ruby/Rails comes in [1].
As Agilistas
we’ve always delivered software early and often. But, Ruby/Rails gives us the ability to deliver much more, much more quickly. As Chris points out, this makes it cheaper to experiment, and therefor more likely that these businesses will succeed.
To borrow a Perlism, there is generally more than one way to do it. Parker’s corollary is that there’s often a best way. Having built quite a few applications in Ruby/Rails, our experience is that it is the best tool for the job it does.
[1] There’s are other arguments to be made about process, business value, Rails, and the relationship between, but we’ll save that for another post.
About the Author
