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

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

I also agree with the argument made by others that re-implementation
takes less than the first implementation but it may be more true for
their first re-implementation in "better" Java.

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.

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

--

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,

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.

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).

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

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,

James

--

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.

On Tue, 22 Mar 2005 13:03:22 +0900, Navindra Umanee

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.

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.

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.

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.

Rails may not provide an order of magnitude productivity increase but I
know it does provide a productivity increase.

Before rails:

I can give you features X, Y and Z for Q dollars

After rails:

I can give you [A-Z] features for Q dollars.

You spend the same amount of time and make the same amount of money but
you give them a *much* better product. So when that customer has another
project who do you think they will come to? The guy still offering just
X, Y and Z or the guy offering [A-Z]? It more about increasing the value
to the customer. Increasing customer value gives you a competitive
advantage which will lead to continual work. That is where Rails will
help make a web-consulting business successful.

Of course a surefire way to please the customer would be to charge them half
as much and deliver twice as many features.