From: Joseph <jlhurtado@...>
Date: 2006-09-05T02:10:11+09:00
Subject: Re: Joel Spolsky on languages for web programming

Vidar,

Risk Management IS NOT equivalent to FEAR, in that you are right.

However, as I said earlier, no SIGNIFICANT progress can be expected
without some risk.  Risk Management is about dealing with risk, not
eliminating it.

Ruby and Ruby on Rails are not the safest choice, but I believe they
are one of the very best choices for web development.  There is a
slight risk in it, but not enough to stop any bold, courageous
corporation, startup or even lone developer to create great software
with it.

Joel and people who share his views, equate Risk with FEAR.  That is
their main mistake.  Ruby is ready now... not for everything, but is
uniquely ready for web development, that is I believe a fact.

As another poster mentioned, there is an evolution in the adoption of
technology.  Ruby is still with the early adopters, but that does not
mean is not mature enough for critical applications.

What will prove me right however is not my rationale here or in my
previous post, but TIME, time will prove those who sticked to Ruby and
Ruby on Rails did so wisely, because TRUTH is tested in time.... I
believe Ruby is ready now, many people disagree, but ultimately time
and people using Ruby for critical applications will be the deciding
factor.

I love this quote from the Linux Advocacy video Red Hat produced
recently, it is incredibly accurate to this issue we are discussing,
and I recommend everyone to watch it, I will quote it here:

"Despite Ignorance
 Despite Ridicule
 Despite Opposition
 Despite it ALL
 TRUTH HAPPENS"
 Source: http://www.redhat.com/truthhappens/

Time will tell us indeed, but I am not waiting for the jury, I am
learning Ruby and RoR now, eager to apply it to create cool, amazing
web applications... isn't that the whole point?  To push technology?
To make it fun again?  To innovate?

Jose Hurtado
Web Developer
Toronto, Canada


Vidar Hokstad wrote:
> Joseph wrote:
> > Although I respect Joel very much, I believe he makes a fundamental
> > mistake in his reasoning.
> >
> > Basically what he is saying can be deconstructed this way:
> >
> > * Do not risk developing in new cutting edge technology. Even if
> > successful proof of concepts are already out there (37 signals et. al)
> > * Use what most people use: PHP / J2EE / .Net not what most experts
> > tell you to use.  Communities and support are paramount.
> > * Corporations and the people in those organizations favor safety, if
> > your job is on the line go with the tried and true. Take no risks.
> >
> > All three assumptions rely on a single assumption: FEAR.
>
> No. They rely on sound risk management principles.
>
> > * Fear the technology would eventually not deliver.
>
> Replace "Fear" with "Risk" and the above is reasonable if your company
> does not have people experienced in a particular technology. And fact
> is today it is still far harder to find people skilled at Ruby than
> many other languages. More importantly, there is too little experience
> with many Ruby technologies for a company with no Ruby experience to
> _know_ whether Ruby will be appropriate for a specific project.
>
> > * Fear the support will not be sufficient.
>
> Replace "Fear" with "Risk" again. The company I work for, Edgeio, uses
> PHP for our frontend code (but Ruby for our backend) because when we
> started building it I had concerns about the availability of people
> skilled with Ruby in general or Rails in particular.
>
> When we started hiring those concerns were validated: It's proved
> extremely hard to find people with Ruby experience. While it's
> certainly getting easier rapidly, not everyone can afford to take the
> risk. In our case I decided to start phasing Ruby in for small self
> contained components in our backend, and gradually take it from there
> as we get enough Ruby skills through training or hiring, which has
> proven to work well and meant that in the event that we'd run into
> unforeseen problems, the effort involved in switching back to another
> language would have been limited.
>
> > * Fear regarding your job safety as a corporate developer or manager
> > who chooses Ruby or Ruby on Rails for some mission critical project.
>
> Which is very valid if you make a choice detrimental to the company,
> regardless which language it involves. As much as I love working with
> Ruby, if someone working for me picked it for something inappropriate,
> and the project tanked badly, they certainly would have to take the
> responsibility for the language choice. If you don't have Ruby skills,
> or your team doesn't have sufficient Ruby skills, or there aren't
> enough skilled Ruby developers available in your location, picking it
> for a high risk project will certainly not speak to your favor with any
> risk
>
> "Fear" as you say, or "risk" is an important decision factor for any
> conscientious manager. Deciding what level of risk is appropriate for a
> project vs. the potential payoffs is one of the most important skill a
> manager must have to make good decisions.
>
> They key is whether you/your team has or can easily aquire the skills
> required to minimise the risks and maximise the payoff. For many teams
> that will not be the case when dealing with any specific new tech.
>
> As for "successfull proof of concepts", they mean nothing unless a) you
> have the same skills and resources as the company in question, and b)
> your project is sufficiently similar. Which means most decisions about
> technology tends to boil down to 1) what your team knows to a certain
> degree, 2) which technologies are the most widely deployed. Ideally
> you're looking for an intersection.
>
> _Sometimes_ the payoff in trying a technology that your team is
> inexperienced with or that isn't widely deployed is large enough to
> outweigh the risks, or the risks are mitigated by your teams experience
> (in the case of tech that isn't widely deployed) or by the available
> pool of external experience (in the case where your team doesn't have
> the skills), but that is not a decision to take lightly.
>
> I am all for using Ruby, and I think a lot of companies that aren't
> using Ruby could get great benefit from testing it. But on low impact,
> low risk, simple projects first. Not because Ruby in itself is
> inherently high risk, but because few companies have enough experience
> with Ruby to jump right into using it on a large or high profile
> project.
> 
> Vidar