Compound Thinking

Silver Bullet on Rails?

I am giving a presentation on Rails at the Washtenaw Linux Users Group this week, so I thought it would be a good time to get a few ideas about productivity and Rails out of my head and down on paper.

I’ll post a link to the presentation later this week, but for now, I’d like to explore the big hairy audacious claim that’s been floating around there about Rails. People have said that they are 10x more productive in Rails than they were in Java, Struts, and Hibernate.

What makes this claim so controvercial is that it goes against the received wisdom that in software development there is no “silver bullet.”

So I thought it would be interesting to take another look at the 1986 essay that started it all No Silver Bullet by Fred Brooks. Which in my experience is much more widely talked about than read. I’d like to highlight one quote:

How much of what software developers now do is devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all the effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement.

I think this gets to the essence of the problem. How much of what we do is dealing with the quirks and idiosyncrasies of the technology we use, and dealing with extraneous implementation details? The Lean Manufacturing side of my brain says we should probably be asking this question another way — “How much of what we do is Waste?”

If you follow the logic, what Fred Brooks is saying is not that an order of magnitude of productivity enhancement is impossible, just that an 10x improvement would mean that:

• 90% or more of what we do now is waste
• we can cut that waste to near zero

While they may seem like absurd statistics, I think both of them are often true.

Your customer wants working code — not meetings, detailed design specifications they can’t even understand, and bug lists!

Outside of IT, there are studies that show that many product development teams have %80 of their time allocated to non-value added activities. This is also true of software teams who spend time on status update meetings, communication planning, scope control, and training. And processes like CMM level 4 certifications often buy repeatability by increasing the burden of non “value-added” tasks.

Your customer doesn’t care how much code you produce, they just want software that works!

This gets us to the heart of the Rails proponent’s claim that using it can make you more than 10x more productive than you were in Java. This claim is based on the idea that even when you are actually sitting in front of your computer writing code, you there’s still waste that can be removed.

Ruby, Python, and Perl, as dynamic languages reduce some of the overhead of Java’s type system. And Rails reduces to near zero the effort required to keep the database schema, ORM code, and model objects in sync. Rails also reduces the mental overhead produced by non-intuitive naming conventions. So, there is certainly some real, and measurable improvement in programmer productivity just by moving to Rails.

The bad news, is that this isn’t going to make you 10x more productive. So far, the best study I’ve seen is shows that Rails has about %60 less code than the equivalent Java. If this is right it means you might be three times as productive in Rails as you would in Java.

Nice, but no silver bullet, right?

Well, there are also other benefits of working in Rails.

Since most Rails applications are developed by smaller smarter teams, there tends to be less team communication overhead on a rails project. Not only that but the nature of Rails development encourages incremental delivery, that removes a lot of waste in terms of over-specification, developing un-used features, and maintaining a complex scope control system.

Rails also includes easy ways to do unit and functional tests, which can significantly decrease the amount of time you waste finding and fixing bugs.

So, what’s the bottom line?

Using a dynamic language like Ruby means less code, which makes you faster. Rails’ full stack integration, means less code which makes you faster. Rails philosophy of convention over configuration means less XML configuration files, which makes you faster. Rails inclusion of a test environment by default, as well as a convenient unit testing framework means you are less likely to write buggy code — and that makes you faster too. All this plus the productivity gains from not having to communicate with a large team and the ability to easily do iterations, can definitely make you ten times more productive.

That said, you could probably get most of this from running another web development framework in a dynamic language, and working with a small team, and doing unit testing.