Code Monkeyism

Programming is hard by Stephan Schmidt

Grails more productive than Rails

Catchy title. But the guys from ALTERthought have some - much needed - numbers. Their numbers show Grails to be more productive than Rails, which is in turn more productive than Spring and pure JEE. As I’ve argued for years, there is no science in computer science. We need to put facts back into computer science. Hard numbers instead of faery tales. Hacknot thinks so too. Thanks for the real numbers. Two thoughts:

  1. This is development effort, not maintenance. Glass shows that 40 to 80 % of effort go into maintenance.
  2. We compared Grails to Seam and think they have much in common. Seam productivity should be nearer to Grails than to the standard JEE stack

Thanks for listening.

About the author: Stephan Schmidt is currently a team manager at ImmobilienScout24 in Berlin. Stephan has been working as a head of development and CTO. He has used a lot of different technologies in the last 20 years including Java, Rails and Python. Stephans main field of interest is maintainablity and productivity in software development. Want to know more? All views are only his own.

If you did like this article but you don't want to subscribe to new articles with your reader, you can follow me on Twitter or subscribe to new posts with your email:

Comments

Numbers? Really? Go back and read the article…specifically “the actual productivity of Grails is outperforming our estimate for J2EE, Java/Spring, and, yes, Rails.”.

ACTUAL versus “our ESTIMATE”? How anyone can compare the actual results in one framework versus what they estimated another would take and consider it a valid comparison is beyond me.

The article is spun tripe, unfortunately. Nice looking graph though.

stephan

Go back and read the article.

They have been doing many JEE, Spring and Rails projects. They have been collecting metrics for all those projects for feature gains versus efforts (productivity).

Now for a Grails project they took the actual numbers for that project and compared them to what the actual project would cost with the other technologies. They compared the numbers they have for productivity (features/effort) of other languages and estimated the progress of their Grails project would it be done with the other languages.

They are a consulting and development shop. it’s clear that they don’t do a big project in 4 technologies just to compare productivity.

Peace
-stephan

Which honestly changes nothing. It’s still estimates versus actual, and thus a very flawed comparison. Their past experience really means nothing more than something to appeal to for authority.

stephan

“Nothing.”

From my point of view it does. And it’s much better than the dumb “10x faster”[2] from the Rails community when talking about productivity. And their methodology is clearly explained in the article and is much better than other ones, which also compare different projects without having sufficient metrics to do so. But your point of view may vary. I agree the best way would be to do exactly the same projects with different plattforms and collect the metrics.

Another interesting point is that Rails is 2x faster than JEE and 1.5x faster than Spring. Others made the same[1] observations.

If you have - non flawed - experiments for language and plattform productivity with numbers for initial development and maintenance, feel free to post them here. I’m interested in all of them.

Peace
-stephan

[1] There are more people which claim 1.1x to 2x increase in productivity, but also only from comparing different projects, not the same one.

[2] which would be 1000% - a ludicrous claim.

“What would you think if I told you that you could develop a web application at least ten times faster with Rails than you could with a typical Java framework?” Curt Hibbs, OnLamp

“David Geary, who has authored books on Java and sits on the technical committee for the latest Java Web programming model, has found that Ruby on Rails is five to 10 times faster than comparable Java frameworks.” ZDNet

franklin yaeger

Stephan is right .. shop appears to have collected historicals and are using a methodology for estimation that they did not pull out of their @ss — Gustav Karner/Barry Boehme. Infact, the very tool they use is written in — yes — RoR (or so they claim). Either way, its good to finally see some data.

Leave a Reply