Joseph wrote:
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
Almost every major decades-old Fortran code, for example, is