Is Ruby on Rails a Silver Bullet?

This article originally appeared upon on texperts.com

Here at 82ASK, we’ve been using Ruby on Rails for well over a year, and we love it. We switched to Rails because we believed that we would see dramatically better productivity, and (in the main) that’s how things have turned out.

Something’s been bothering me about this though. Back in 1986, Fred Brooks wrote his brilliant paper No Silver Bullet (included in the Anniversary Edition of The Mythical Man Month). It was, and remains, one of the most influential papers ever written about software engineering. In it he argues that there will be no more techniques or practices that will serve as “silver bullets” and massively improve programmer productivity.

So, how do we square this circle? Was Brooks wrong? Has David Heinemeier Hansson (the creator of Rails) uncovered something that invalidates his argument? Or are we fooling ourselves, and Rails isn’t really giving us the kind of productivity boost we think it is?

Essence and Accident

Brooks’ argument is that we are faced with two different types of difficulty in software development — essential and accidental.

Essential difficulties are intrinsic to whatever problem the software under construction is intended to solve. No technology or approach can remove an essential difficulty as it is a fundamental feature of the problem.

Accidental difficulties by contrast are those we must overcome in order to solve the problem, but are not intrinsic to its solution.

Early on in the history of software engineering the main difficulties we faced were accidental ones — working out how to represent complex data structures as bytes in memory, converting algorithms into machine code, etc. But these were fixed pretty quickly when high-level languages and a few other key technologies were developed, and what we’re left with are the essential difficulties.

Sure, there are a few things which have come along which have made things better. Object-oriented programming has certainly helped and (even though it had been invented long before Brooks wrote his paper) the recent wide adoption of garbage collection hasn’t hurt either. But these are incremental improvements only.

Is the Rails advantage real?

So are we imagining things? Does Ruby on Rails really deliver the kind of productivity gains we think it does?

Our experience with Ruby on Rails started over Christmas 2005, when as a way of finding out whether there really was anything in the hype, I decided to have a go at duplicating the functionality of one of our existing systems in Rails. I was amazed by how quickly I was able to get things up and running. Crucially this initial productivity boost was maintained as the software grew (in stark contrast to, for example, the temporary productivity boost provided by a code-generation wizard).

On the back of this experience (and after a lot of internal debate!) we decided to rewrite one of our existing PHP systems in Ruby on Rails in June 2006. Including load testing, end-user trials etc, it took three developers six weeks to entirely duplicate a 22,000 line PHP system with approximately 5 man-years of work invested in it. The final Rails system consisted of 6,000 lines of code.

Of course, the rewrite would have been faster whatever technology we used, because we had learned lessons developing the previous system (although we needed to be careful of another pitfall identified by Brooks, the second system effect). But we could never have hoped to achieve what we did without Rails.

Since then, we’ve continued our transition and now all our internal systems use Rails. And we have continued to see a similar productivity boost.

Our experience isn’t unique by any means. In his book From Java to Ruby, Bruce Tate (who has written several books on rapid development in Java) describes his introduction to Ruby. He and Justin Gehtland had been working on an application in Java for four months. Justin implemented a Rails version of the same app in 4 nights.

A quick search of the web will scare up many similar stories. So there certainly seems to be reason to give credence to the assertion that Rails brings something pretty powerful to the party. The question is what? And how do we reconcile it with “No Silver Bullet”?

Pages: 1 2 3

6 Responses to “Is Ruby on Rails a Silver Bullet?”


  1. 1 ilan berci April 5, 2007 at 3:43 pm

    Simply fantastic artile, (I especially appreciate all the links to the referenced articles!) I agree with you a 100% in the fact that rails provides benefit by simply addressing accidental difficulties but that is what they stated from the very start (as long as you stay on the path and follow their sensical conventions).

    Likewise, it obviously won’t improve efficiency in addressing your bussiness model (which framework does) and never make such claims. You need Ruby for that! 🙂

    Thank you for taking the time to write this, I will forward it to my development group.

    ilan

  2. 2 jerzy prekurat April 5, 2007 at 9:02 pm

    My initial lack of enthusiasm towards RoR was based exactly on “No Silver Bullet” way of thinking: tools do not address essential difficulties of the problem, most tools address accidental difficulties well enough, so what is the big deal ? YAT, YAT, YAT… (yet another tool)

    Well, there is something: it works….

    I think this article comes long way towards answering – why it works and where it works. Thanks !

    jerzy

  3. 3 Bruce Tate April 6, 2007 at 2:20 pm

    Fantastic article. You have said it better than I. I’ve since taken a CTO role at a company called WellGood, LLC, the makers of ChangingThePresent.org. We’ve come to understand that Rails can make a dramatic difference in our overall productivity. It can’t improve our business processes.

    Said another way, if technology is your bottleneck, Rails will rock your world. In this spirit, Rails has been very good to us. It’s very close to a silver bullet in that sense. We’re simply applying a more appropriate technology to the task at hand.

    But technology usually isn’t the bottleneck. So in some cases, we make bad decisions, and actually dig a hole faster than before. All in all, we’re good enough from a process perspective, and we have a close enough problem to the ideal Rails niche, that we’re able to be very productive.

  4. 4 John May 27, 2007 at 3:38 pm

    Nice article. One word: WebObjects. If you know this Rails is “meh”, if you don’t Rails is GOD!

  5. 5 Sam Halliday August 14, 2007 at 8:07 am

    It’s interesting to note that Bruce Tate and Justin Gehtland wrote an app in 4 months in Java, then ported to Ruby in four days. Note that I said “ported” not “wrote”. After 4 months of discovering the architectural bugs and learning the traps and pitfalls of a program… rewriting it should be a breeze! Still, 4 nights is bloody fast.


  1. 1 There might just be a Silver Bullet « 3Spoken Trackback on April 10, 2007 at 7:02 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





%d bloggers like this: