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