7 June 2007
Revenue on Ruby on Rails …
Okay, so its not the most poetic title, but that’s what you get when Captain Alliteration gets your login and password. For the last 18 months we at ALTERthought have been diving into the deep end of the Ruby on Rails (RoR) pool. The technologies are clearly compelling for a number of reasons that are best left to the engineers and architects to discuss. From my (business) perspective, in our dealings with many of our clients, my message is clear. RoR gets you to market much faster with more adaptability than other paradigms. Hence, the “revenue” part of the title — yes, I agree; its a bit plastic. Nevertheless, it gets the point across. For our purposes this ultimate economic benefit of RoR is encoded via our software application estimation tool, Planix. We’re able to model the potentil level of effort from a Rails application and compare that figure to other development paradigms.
Obligatory Caveat: While we’ve not built the same application in a variety of langugages to assess the potential savings, we have normalized by analyzing applications of similar complexity with comparable team competencies (using Planix as our steward).
To cut to the chase, in general the economics and adaptability of a Rails-based application versus other applications look something like this –
A medium complexity application with approximately 20 medium-to-high complexity features (use cases or user stories)*

* We are speaking of applications where a ‘pure’ Rails approach is applicable; where other non-Ruby on Rails technologies are not required ro realize the solution.
Pretty impressive, eh? We believe so as well, but — again — just because you can develop faster, does not mean you should. In my next post, we’ll discuss more of the pros and cons of using RoR as your platform of choice.
Technorati Tags: software economics, Ruby on Rails, RoR, Rails productivity, software development costs, time to market,
9 Comments currently posted.
Xin says:
sunjay says:
Xin, its possible you could get more of a productivity boost with Rails depending on how comprehensive your development cycle is. For our part, our tool, Planix, takes into account a process which includes requirements and at least one round of QA. Admittedly, these are full-lifecyle numbers which account for requirements, development, and testing — and at the end of the day - CSS and all the cost/wranglings associated with making your application look “pretty” must still be “paid.”
Cheers,
Sunjay
ALTERthought Blogs » Blasphemy: The Case Against Ruby on Rails says:
[…] EDIT: For completeness and for the sake of those who did not have the time to navigate our blog, In a previous post, we examined the virtues of Ruby on Rails from a business perspective…and the potential economics of Rails in another post ….Technorati Tags: crossing the chasm, Ruby on Rails, RoR, Rails productivity, technology adoption, Groovy, Grails, Trails, time to market, […]
ALTERthought Blogs » Go-Railers in the Midst … says:
[…] Ruby on Rails as a Platform of Choice? The Case for Rails: examines why a business person *should* evangelize Rails as his or her chosen platform Revenue on Ruby on Rails: examines our quantitative observations about productivity using the Rails framework Two of the most interesting, legitimate, and constructive responses/rebuttals to both my post and the comments it engered that I’ve seen are the following: […]
GSIY … Ruby-Rails Portal says:
[…] $$$$$ -You get stuff sooner. Its that simple. As a stakeholder, I’ve seen Rails teams turn features around in ½ the time as it would have taken them to do it using J2EE or .NET (see this post for a little comparison on development speed) […]
GSIY … Ruby-Rails Portal says:
[…] EDIT: For completeness and for the sake of those who did not have the time to navigate our blog, In a previous post, we examined the virtues of Ruby on Rails from a business perspective…and the potential economics of Rails in another post …. […]
GSIY … Ruby-Rails Portal says:
[…] Ruby on Rails as a Platform of Choice? The Case for Rails: examines why a business person *should* evangelize Rails as his or her chosen platform Revenue on Ruby on Rails: examines our quantitative observations about productivity using the Rails framework […]
GSIY … Ruby-Rails Portal says:
[…] Grails is the latest in our effort to benchmark technologies and their respective productivity; to date, Grails is showing itself to be slightly more productive than using Rails - to the tune of about 5.8%. As others have observed, we do believe Grails to be a “formidable challenger” to Rails .. and we’re gathering data to back up our claim. Yes, premature precision will get us in trouble and the sample size is characterized by 1 project that is 40% complete, but … well, you get the picture. […]
Orban Botond says:
I made another kind of comparison.
I have implemented the “payroll” application from “Agile Software Development” in ruby. It took me 10 times less LOC than the author wrote it. Great isn’ it?
Here is my post about it:
http://orbanbotond.blogspot.com/2008/01/ruby-on-rails-productivity.html


Interesting numbers. I personally would have thought Rails would provide more of a productivity boost than that.
Coming from PHP with no framework, it is certainly a joy to code in Rails. The framework totally enables me to focus on the functionalities, and not trying to figure out how to best organise folders and files, which I was doing lots of in PHP.
I think that’s one of the main bonus of Rails. Not only does it have all the niceties like ActiveRecord, but it helps you to structure your code which you might not know how otherwise.