Support for 10x Productivity Increase with Rails!

[Curt Hibbs]

I got a lot of flack for what I wrote in my ONLamp.com article on Rails when
I said you could get a 10x productivity increase using Rails vs. a typical
Java framework. The funny thing is that I thought I was being conservative!

Anyway, I spent some time talking with Bruce Tate this weekend (author of
Better, Faster, Lighter Java; Bitter Java; and Bitter EJBs) and he was able
to confirm that my claim is *not* out of line (he likes to say 5x to 10x
increase). Obviously your mileage will vary depending on circumstances, but
based on the details I got from Bruce, I still think that 10x is a good
ballpark number.

Some of these details have been reported before (DHH even commented on some
of this in his blog), but if you dig a little below the surface I think it
is even more telling, so please forgive me for re-telling the story...

Bruce Tate and his partner Justin Gehtland were engaged by a client to
replace an web app that had originally taken the company a year to develop.
Justin took 4 months to reimplement this web app using Spring and Hibernate.
Bruce characterized Spring/Hibernate as among the most productive frameworks
available in the Java space.

Recently, Justin decided to re-implement with Ruby on Rails. Bruce said that
this took a total of 5 days (Justin's weblog reported 4 days for 80%
completion so, presumably, 5 days is for the whole thing)!

Now this was widely reported, and so far there's nothing new here. But
consider this:

- Justin is a recognized *expert* in Spring and Hibernate.
- Spring/Hibernate are not your typical Java framework
(i.e., not Struts), but are the current best-of-breed.
- Justin was a *novice* with Ruby and Rails and knew
practically nothing about either one.

Despite being an expert in the best-of-breed Java frameworks and a novice in
the Ruby on Rails frameworks, he still managed an 8x improvement in
productivity -- this is very compelling! I can easily see how the
productivity increase would be even higher if compared with a Struts-based
implementation written by a non-expert.

But there is more... the Rails implementation actually ran faster than the
Java implementation! Now this, too, was previously reported. This had
baffled me somewhat, but Bruce thinks he knows why. He thinks its primarily
because Rails has fewer layers to go through than the java stack, and the
fact that the ActiveRecord ORM layer is much less generalized than Hibernate
and can, therefore, be implemented much more efficiently.

Anyway, it feels good to have my 10x claimed confirmed by an industry expert
to stated that he, too, was skeptical... until he had first-hand experience.

Curt

PS
Bruce Tate and David Geary (author of Core Java Server Faces, Core JSTL,
and more) have signed with O'Reilly to write a "Rails Developer Notebook"
(obviously one of O'Reilly's new Developer Notebooks series).

 

[Glenn Parker]

Bruce Tate and his partner Justin Gehtland were engaged by a client to
replace an web app that had originally taken the company a year to develop.
Justin took 4 months to reimplement this web app using Spring and Hibernate.
Bruce characterized Spring/Hibernate as among the most productive frameworks
available in the Java space.

Recently, Justin decided to re-implement with Ruby on Rails. Bruce said that
this took a total of 5 days (Justin's weblog reported 4 days for 80%
completion so, presumably, 5 days is for the whole thing)!

The devil's advocate would ask, how much of that first four months was
devoted to Justin developing his expertise in the application itself?
Once you've mastered an application's logic, you have a distinct
advantage when re-implementing it in another environment.

 

[Lothar Scholz]

Hello Glenn,


GP> The devil's advocate would ask, how much of that first four months was
GP> devoted to Justin developing his expertise in the application itself?
GP> Once you've mastered an application's logic, you have a distinct
GP> advantage when re-implementing it in another environment.

Correct. And you can implement the first 90% of an application in 10%
of the time you need for a 100% implementation.

 

[James Britt]

The devil's advocate would ask, how much of that first four months was
devoted to Justin developing his expertise in the application itself?
Once you've mastered an application's logic, you have a distinct
advantage when re-implementing it in another environment.

I agree; I find that Ruby gives me an 11x increase ("Well, it's one
faster, isn't it? It's not ten." ) in productivity over Ruby whenever I
decide to rewrite a Ruby app in Ruby.

A good deal of development time is figuring out where the specs or goals
are wrong or incomplete, and sorting things out. Once I've written
something, in whatever language, porting it over (or simply rewriting
it) almost always goes faster; there's less thinking involved.


I have a problem with assorted claims based on anecdotal testimony,
however expert and/or reliable the person making the claim. They almost
always come off sounding like biased hype, and the lack of any objective
proof allows people to go away believing whatever the want to believe
anyway.

Much better, I think, to make demonstrable assertions about the tool or
language itself, and let others make their own comparisons based on
their own experience.

James Britt

--

http://www.ruby-doc.org
http://www.rubyxml.com
http://catapult.rubyforge.com
http://orbjson.rubyforge.com
http://ooo4r.rubyforge.com
http://www.jamesbritt.com

 

[Eric Hodel]

--Apple-Mail-25--16489099
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

I got a lot of flack for what I wrote in my ONLamp.com article on
Rails when
I said you could get a 10x productivity increase using Rails vs. a
typical
Java framework. The funny thing is that I thought I was being
conservative!

Anyway, I spent some time talking with Bruce Tate this weekend (author
of
Better, Faster, Lighter Java; Bitter Java; and Bitter EJBs) and he was
able
to confirm that my claim is *not* out of line (he likes to say 5x to
10x
increase). Obviously your mileage will vary depending on
circumstances, but
based on the details I got from Bruce, I still think that 10x is a good
ballpark number.

43 Things was implemented and released by 5 people in under 3 months.
There was only one Ruby expert (me) and I spend half my time playing
sysadmin.

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-25--16489099
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCPyXJMypVHHlsnwQRArRiAKCymauU+uraE1rR1LJ2R7s1wm3hGACfZ3Lf
rCPDMSw0rAil84m/tKBvQc4=
=KN8O
-----END PGP SIGNATURE-----

--Apple-Mail-25--16489099--

 

[Glenn Parker]

43 Things was implemented and released by 5 people in under 3 months.
There was only one Ruby expert (me) and I spend half my time playing
sysadmin.

If it's not too much trouble, could you see how much time it takes to
re-implement it using Spring/Hibernate? Just curious...

 

[Bob Aman]

The devil's advocate would ask, how much of that first four months was

I agree; I find that Ruby gives me an 11x increase ("Well, it's one
faster, isn't it? It's not ten." ) in productivity over Ruby whenever I
decide to rewrite a Ruby app in Ruby.

A good deal of development time is figuring out where the specs or goals
are wrong or incomplete, and sorting things out. Once I've written
something, in whatever language, porting it over (or simply rewriting
it) almost always goes faster; there's less thinking involved.

Ok, but what about when you want to add new features to an existing
ruby app. What if you're trying to beat your competitors to the
punch? If nothing else, I'd pick ruby simply for the ease in hacking
something together quickly. I just picked ruby up recently, and
thanks to the whole 'least surprise' business, I find that even though
I don't really know what I'm doing, I still manage to do things
exactly the right way on the first try the overwhelming majority of
the time. In Java, and many other systems, it takes at least 2-3
rewrites of a feature before I'm really happy that I got the thing
right... and I know I'm not alone in this. Almost no one ever designs
something totally new without making any mistakes. Even Apple is
working on a 5th generation iPod.

I know people don't really like anecdotes, but Ruby gives me a warm
fuzzy feeling and Java simply doesn't. I doubt I'd claim a 10x
improvement in productivity, but I can definitely say there's a
substantial one, and it's big enough that it's hard to measure.

And actually, so far, I don't think I could claim an '11x improvement
writing something in ruby over writing something in ruby'. So far,
rewrites take me almost the same amount of time as the original code
took to write, because the limiting factor, thus far, seems to be my
typing speed.

 

[Curt Hibbs]

I know people don't really like anecdotes, but Ruby gives me a warm
fuzzy feeling and Java simply doesn't. I doubt I'd claim a 10x
improvement in productivity, but I can definitely say there's a
substantial one, and it's big enough that it's hard to measure.

Just to be clear, the 10x claim is specifically for web app development
using Ruby on Rails vs web app development using mainstream java frameworks.
I make no such claim for general Ruby vs Java development.

Curt

 

[Bill Kelly]

I got a lot of flack for what I wrote in my ONLamp.com article on Rails when
I said you could get a 10x productivity increase using Rails vs. a typical
Java framework. The funny thing is that I thought I was being conservative!

So... how about some Rails vs. Wee comparisons ??? <grin>

Seriously, though, if anyone has tried both Rails and Wee, any
notes on how the two frameworks compare or contrast would be
much appreciated.

Trying both Rails and Wee is on my TO-DO list but I haven't
gotten to either yet. I'm interested in Wee because of its
use of continuations. I can expect an additional 7.94322773
times increase in productivity from that, right???


Happy Rubying,

Bill

 

[Bob Aman]

Just to be clear, the 10x claim is specifically for web app development

using Ruby on Rails vs web app development using mainstream java frameworks.
I make no such claim for general Ruby vs Java development.

Good point. I was refering to Ruby in general, but really Rails
specifically. I have quite a bit of stuff related to rss and web
services that could easily exist independently of Rails, but it was
all written for the purpose of plugging into it. I still feel more
productive whether I'm working on the independent stuff or if I'm
working on things that are clearly within the domain of Rails. Again,
this is all anecdotal. But I think we'll ultimately find that it's
impossible to escape the anecdotal issue.

 

[James Britt]

Ok, but what about when you want to add new features to an existing
ruby app. What if you're trying to beat your competitors to the
punch? If nothing else, I'd pick ruby simply for the ease in hacking
something together quickly.

Oh, I agree, and this one of the selling points I turn to when
encouraging people to use Ruby over, say, Java or PHP. But I try not to
make any claims involving direct comparisons. I see if I can stick to
describing features inherent to Ruby, with examples.

I, too, have found that one can take a guess at how something is
supposed to work and be right most of the time. And I try to convey
this impressive regularity and the relative absence of special cases as
an essential feature of being productive with Ruby, more so than any app
or library.

I'm doomed if I get into a pissing match with an advocate of some other
language, as there always seems to be some feature or tool that I know
nothing about. I've never used Spring or Hibernate or whatever is cool
this week, so I can't tell Java folks that, say, Og/Nitro will be
x-times anything for them.

My affection for Ruby, though, is not based on any particular tool, but
the language itself and the people who support it.

In the end, people preferring to use Java or PHP or Python or whatever
will look at Wee or Nitro or Rails, steal as much as they can, and be
better off, and I wish them well. But it's much harder to copy a
community and a culture.



James

 

[Eric Anderson]

I was going to continue to be my usual lurker self but I just couldn't
resist responding to this. First I want to say I am a fan of Rails and
Ruby in general. I am currently developing a decent size project in
Rails and have contributed several patches to the Rails framework itself
so I am by no means a visiting troll.

I got a lot of flack for what I wrote in my ONLamp.com article on Rails when
I said you could get a 10x productivity increase using Rails vs. a typical
Java framework. The funny thing is that I thought I was being conservative!

I think the problem with this statement is that it is so undefined.
Under what circumstances are we talking about here? Every development
environment is different with so many factors that will determine the
speed of development that *nobody* in their right mind would claim a
general X-times increase in productivity.

It is probably best explained in Brooks' essay "No Silver Bullet". If
you want to really know why any improvement in general will not produce
an order of magnitude increase in productivity (which is what you are
claiming by 10x) then read that article (or the whole Mythical Man Month
book). For those who read Cliff's Notes, the basic concept is can be
summed up in this passage from the essay:

"I believe the hard part of building software to be the specification,
design, and testing of this conceptual construct, not the labor of
representing it and testing the fidelity of the representation."

Basically we can't get a order of magnitude increase in development time
because a majority of development time is spent in specification, design
and testing *not* implementation. Even using agile languages, being a
good programmatic programmer and using RAD and XP programming
methodogies I believe this to still be true. These methods only help
remove what Brooks calls "Accidental Difficulties" but the fundamental
complexities of understanding, designing, implementing, testing and
verifying your system remain. The accidental difficulties removed are
not going to provide an order of magnitude increase and neither is a
boost in implementation.

Only in certain limited cases do I think your statement might be true.
The two main cases I can think of off the top of my head are:

* When the scope of the project is small. In small projects the
implementation time tends to increase in percentage compared to the time
spent on other aspects of software development (understanding, design,
etc.). This is because the complexity is not as high.

A good example of this I think is TaDa List. Don't get me wrong. I think
TaDa List is a great little project. It is useful, easy to use, pretty,
and fun. But fundamentally it is a simple todo list. It allows you to
share a list, it uses XMLHttpRequest to reduce response time and update
instantly, but honestly we aren't talking about rocket science here (or
even a "standard" enterprise app like a CRM, Accounting Software or any
other complex data driven application). I am not trying to rag on TaDa
list in any way. I think it is a great app. I am merely trying to show
why in this case the increase in development time might be the order of
magnitude increase claimed.

* The other case I can think of is reimplementation. If you are
reimplementing something (or are even on your 3rd or 4th
reimplementation) then your implementation time will also be a larger
percentage than normal. This is because much of the understanding,
design and verification work has already been done. You are taking all
your knowledge and experience and using it in the new project which
greatly reduces your total development time (with or without rails).

Obviously your mileage will vary depending on circumstances, but
based on the details I got from Bruce, I still think that 10x is a good
ballpark number.

I agree that depending on details the mileage may very. I feel the
mileage varies so widely that I don't think you can even give it a
ballpark number.

Recently, Justin decided to re-implement with Ruby on Rails. Bruce said that
this took a total of 5 days (Justin's weblog reported 4 days for 80%
completion so, presumably, 5 days is for the whole thing)!

Careful with this statement. As I think someone else noted on this
thread, some people claim 90% of your time is spent developing the last
10% of your project. I don't know if these percentages are generally
correct but I do feel the concept is valid. 4 days for 80% could still
mean weeks before it is 100%.

Also, this anecdotal evidence falls under the "reimplementation" special
case. This says nothing about general web application development.

Anyway, it feels good to have my 10x claimed confirmed by an industry expert
to stated that he, too, was skeptical... until he had first-hand experience.

I feel that it doesn't support your claim in any way. You made a general
statement which history has show to be unlikely the be true. Your
"confirmation" is simply anecdotal evidence and even this it is a
special case anecdotal evidence.

I don't want this post to feel like flame-bait. I am not trying to rag
on any person or project. I just feel that saying Rails has a 10X
productivity increase will be generally inaccurate and misleading.

Not only that I feel it reflects badly on the technology being talked
about. I had been using Rails prior to your Rails article. I think your
article was a great introduction to Rails, but if I had read your
article and not known about Rails I would have been turned off to Rails
because of that statement. I would have figured that if someone thought
a web-development framework could generally give a order of magnitude
productivity increase then they must not have learned lessons of past
software developers (such as Brooks) and this would probably had made me
put Rails towards the bottom of my "to look into" list. After all how
good can the framework be if they hadn't learned from history?

Luckily I already knew Rails so I did not let that statement distract me
and I just enjoyed the rest of a good article.

Just my two cents,

Eric

 

[James Britt]

I was going to continue to be my usual lurker self but I just couldn't
resist responding to this. First I want to say I am a fan of Rails and
Ruby in general. I am currently developing a decent size project in
Rails and have contributed several patches to the Rails framework itself
so I am by no means a visiting troll.
...

Thanks for delurking. You've made important points.

I don't want this post to feel like flame-bait. I am not trying to rag
on any person or project. I just feel that saying Rails has a 10X
productivity increase will be generally inaccurate and misleading.

Not only that I feel it reflects badly on the technology being talked
about. I had been using Rails prior to your Rails article. I think your
article was a great introduction to Rails, but if I had read your
article and not known about Rails I would have been turned off to Rails
because of that statement. I would have figured that if someone thought
a web-development framework could generally give a order of magnitude
productivity increase then they must not have learned lessons of past
software developers (such as Brooks) and this would probably had made me
put Rails towards the bottom of my "to look into" list. After all how
good can the framework be if they hadn't learned from history?

Luckily I already knew Rails so I did not let that statement distract me
and I just enjoyed the rest of a good article.

There's a fine line between promotion and hype, and the Rails hype may
be counterproductive. I can understand why people get enthusiastic,
why they want everyone to drink the Rails Kool-Aid; it's great for
business and all, and it's arguably good for Ruby, but at times it just
comes off as strident dogma, marketecture buzz, or dust-jacket blurbs.



James

--

http://www.ruby-doc.org
http://www.rubyxml.com
http://catapult.rubyforge.com
http://orbjson.rubyforge.com
http://ooo4r.rubyforge.com
http://www.jamesbritt.com

 

[Navindra Umanee]

There's a fine line between promotion and hype, and the Rails hype may
be counterproductive. I can understand why people get enthusiastic,
why they want everyone to drink the Rails Kool-Aid; it's great for
business and all, and it's arguably good for Ruby, but at times it just
comes off as strident dogma, marketecture buzz, or dust-jacket blurbs.

Yeah. I have been subject to the Rails hype myself and I have found
myself naturally resistant to it.

I have the feeling that Rails is now at the position that Zope was a
few years ago. A lot of excitement, craziness and hype until reality
sets in.

Anyway, don't get me wrong. Rails is probably the opposite of Zope in
many ways, although at the same time it face some of the same issues
that Zope does... memory leaks, upgrading pains... it's all there,
just read this list.

Rails is probably worth evaluating, I just haven't really felt the
need given that I've been very happy with Ruby.

Cheers,
Navin.

 

[Joao Pedrosa]

Hi,

Yeah. I have been subject to the Rails hype myself and I have found
myself naturally resistant to it.

I have the feeling that Rails is now at the position that Zope was a
few years ago. A lot of excitement, craziness and hype until reality
sets in.

Anyway, don't get me wrong. Rails is probably the opposite of Zope in
many ways, although at the same time it face some of the same issues
that Zope does... memory leaks, upgrading pains... it's all there,
just read this list.

Rails is probably worth evaluating, I just haven't really felt the
need given that I've been very happy with Ruby.

I'm a sinner in trying to promote Rails. Sometimes it may backfire,
mainly when someone only needs an excuse to avoid it.

It may be clumsy trying to evangelize a technology without being an
expert evangelizer. But there is a vacuum between the "show, do not
tell" that needs to be filled with "tell, do not show".

Fortunately, there are enough technical people to "show" how
everything works, through demos, documentation, examples, tutorials
and answering questions.

Cheers,
Joao

 

[CD Baby]

There's a fine line between promotion and hype, and the Rails hype may
be counterproductive <<


Yes!

The constant hype is what kept me AWAY from Rails for so long!
I just couldn't stomach the constant self-congratulations to it all.

Now I can't stomach the constant other-technology-bashing. (Java, PHP, etc)

Nobody wants their current beliefs insulted.

Can you imagine if Buddhists said "Stupid Christians! Our religion
will make you 10 times happier than this junk you believe now!"

They'd look like a bunch of jerks, and everyone would avoid it until
one day some might look at it deeper anyway, and decide they liked it
anyway DESPITE the bunch of jerks that insulted their beliefs.

When someone only talks about himself you think he's an ass.
When everyone else talks about this person, you pay attention.
It is a fine line.

 

[Joao Pedrosa]

Hi,

be counterproductive <<

Yes!

The constant hype is what kept me AWAY from Rails for so long!
I just couldn't stomach the constant self-congratulations to it all.

Hype is an overused word sometimes. It's like the overuse of troll,
only because you don't agree with someone else's opinion. IT
professionals and geeks overload and overuse some words too much
sometimes.

I agree that it's better to "show, and don't tell." Or better yet,
keep quiet about it and use it to get _your_ job done, forget about
the others. But some people just can't avoid talking about what
they love, me included.

Cheers,
Joao

 

[why the lucky stiff]

There's a fine line between promotion and hype, and the Rails hype may
be counterproductive. I can understand why people get enthusiastic,
why they want everyone to drink the Rails Kool-Aid; it's great for
business and all, and it's arguably good for Ruby, but at times it just
comes off as strident dogma, marketecture buzz, or dust-jacket blurbs.

Hype and rhetoric will always be around. And it's okay to push it away,
if that's not your style.

I just don't want to see us become divided against each other. We have
a strong culture and a common aesthetic. Let's focus on that.

_why

 

[Michael Neumann]

Am Montag 21 März 2005 21:40 schrieb Bill Kelly:

So... how about some Rails vs. Wee comparisons ??? <grin>

Seriously, though, if anyone has tried both Rails and Wee, any
notes on how the two frameworks compare or contrast would be
much appreciated.

I tried both ;-)

Well, if you always have one page at a time displayed on the screen, and the
interactions are not too complex, plus bookmarking is neccessity, then Rails
is better suited than Wee. On the other hand, if you want to build very
dynamic web applications (e.g. like Nemo/Mewa), Wee is better suited IMHO.
Of course you can use Wee for the same tasks as you can use Rails, but it's
initial harder because it's model (separation of render and action phase) is
not that easy to think in (for a beginner ;-).

Trying both Rails and Wee is on my TO-DO list but I haven't
gotten to either yet. I'm interested in Wee because of its
use of continuations. I can expect an additional 7.94322773
times increase in productivity from that, right???

Hm, sure you could.... but keep in mind that there were some memory problem
with continuations. That does not mean they will actually leak memory, only
that I once noticed this. So be careful!

Regards,

Michael

 

[George Moschovitis]

I've never used Spring or Hibernate or whatever is cool

this week, so I can't tell Java folks that, say, Og/Nitro will be
x-times anything for them.

Oh, but you should

tml (George Moschovitis)