On 9/4/06, Chad Perrin <perrin / apotheon.com> wrote:
> If you eliminate risk entirely, you end up guaranteeing failure -- for
> some definition of risk.  Any definition of risk that does not result in
> that end is either meaningless or effectively impossible to eliminate.

Well thats pedantic, you will notice that I said nothing about eliminating
it entirely. I always thought your technology choice should
not add to your existing business risk wherever you can help it.

Currently the way I see it, is that if you choose a java solution over a
RoR solution you are increasing business risk due to the fact that it
will take longer to get your v1.0 up. In the meantime the RoR solution
is getting very polished, and mature and is in a position to ship or secure
revenue or mind share early. Also lengthy development gives the ADD
marketing crowd too much time to get antsy.

The main unanswered question in Rails is whether 'Rails is quicker'
holds true for a sufficiently large application space. Or is this a truism
only in a conventional web app space and green field application to boot
(the Rails Sweet Spot (tm) ).

If you have to do wierd stuff like:
- interact with systems in some non web way (CORBA, SNMP, XML)
- use legacy databases
- run on single-server machines
- do CPU intensive work in requests (e.g. image manipulation)

do you still get to keep the productivity boost? If you don't, the RoR
advantage starts to disappear, and all those other conventional technologies
start to look more attractive. All those 'works as advertised' libraries, and
alternatives of technology choices if your main library/binary is inadequate.
Also a huge volume of proven, documented best practices.


The burden of proof is on Rails to
establish it is ready for prime time.