Re: Using Ruby in a Corporate Environment

I'm also looking at Ruby/JRuby in a very large corporate setting.  Those
hurdles you are talking about are very real, and in many cases, very
legitimate, so you have to do a lot of research and come up with a
plan/strategy to get everyone from point A to point B.  A roadmap.  The
parts of managing the system once it is deployed and the all the other
non-sexy, non-programmy parts of running an enterprise is where you run
into problems, and for good reason.  There is a huge investment in time,
training, blood, sweat and tears in getting all of the enterprise systems
working.  It takes years and years to build that kind of knowledge into the
enterprise.  While you can learn the framework and the basics and knock out
simple things quickly, it is that last 10% that only comes with time and
experience that is the show stopper.  It might take a whole team of very
experienced developers 2 weeks to figure out a problem that only happens
when you are using version X of Linux with version Y of Weblogic along with
Version Z of Oracle and you changed from Version 123.1 to Version 123.2 of
the JRockit JVM.

An enterprise making that kind of move is taking on incredible risk and
therefore, you really have to nail down your roadmap to get it done.  My
own strategy so far is more of a ninja approach.

1.  Start using Ruby/JRuby to do my offline work.  I was able to produce a
log parser on the fly to grab messages that had failed processing and
requeue them in about 15-30 minutes while the other guys were still specing
out the solution in Java.  I did this in front of the boss and a number of
developers who were quickly impressed.  Considering I had been learning
ruby for about 3 days, it was pretty cool =)
2.  Do a lot of "water-cooler" selling.  When you go to lunch or standing
around talking during a break, tell people the cool things you've been
doing with it.
3.  Figure out ways to get it into the environment by leveraging the
environment and not fighting it.  If you are a Java shop, look at
applications that have extensible systems and look at adding scripting
support to those systems.  I happen to have one that fits the bill nicely,
so I'm adding that support now.
4.  Figure out a way to get ruby/jruby to deploy using your existing
infrastructure.  In my case, how can I get JRuby/Ruby into an ear/war file
and have it work?
5.  Don't bite off more than you can chew.  A lot of learning a language
comes after years of struggling with issues, so don't use it with a full
team of new Ruby/JRuby guys who all just read the book and did 'hello
world'.  Pick a small, one-off project and get your feet wet.  Add to
existing stuff if you can.  Don't break anything =)
6.  Worry about performance.  Ruby/JRuby is so incredibly slow on
benchmarks, no one is going to take you seriously if you try to use it for
everything right now.  When you see things like this:
http://www.javaworld.com/javaworld/jw-03-2005/jw-0314-scripting_p.html it
is hard to make the case not to use a different scripting language just
based on speed/familiarity.  Groovy, Python/Jython, Javascript, etc, in my
particular case.  You better have an explanation ready about why in the
heck it is that much slower than everything else and what you think is
going to happen in the next year or so.
7.  Address programmer concerns.  You can laugh and be disheartened about
people that don't want to use your newly found cool language, but it is
their career they are worried about.  Being confrontational about it isn't
going to win you friends or sponsers.  You are only going to convince
people to change by showing them the benefits, not telling them about it.

You have to remember that enterprise businesses are generally there to make
a profit and they are not primarily IT shops.  They don't care how cool or
object-oriented or technically superior a product care.  They really,
really, couldn't care less.  They care about the TOTAL-COST-OF-OWNERSHIP.
They don't care that the tools are free and you can learn them in 10
minutes.  They care about support costs, how it integrates with existing
stuff, how much it will cost to staff up, how they can leverage to make
more money or get more customers or reduce costs.  So most of your
arguments have to be business oriented.



                                                                           
             Steve Molitor                                                 
             <stevemolitor@gma                                             
             il.com>                                                    To 
                                       [e-mail] (ruby-talk  
             04/26/2007 05:01          ML)                                 
             PM                                                         cc 
                                                                           
                                                                   Subject 
             Please respond to         Using Ruby in a Corporate           
             ruby-talk@ruby-la         Environment                         
                  ng.org                                                   
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




---------- Forwarded message ----------
From: Curt Hibbs <[e-mail]>
Date: Apr 26, 2007 12:41 PM
Subject: Re: [stlruby] St. Louis Companies Using Ruby
To: [e-mail]
Cc: "St. Louis Ruby Users Group" <[e-mail]>
Curt,

Thanks for some really helpful pointers.  Love the Spolsky essay.  I'm
sending it to my boss and our project managers.

The two hurdles to using Ruby more at my company are convincing my
boss, and convincing the developers.  My boss is worried about the
usual stuff:  staffing, training, scalability, etc.   You've helped me
with the staffing and training issues, and we can do some benchmarking
to test scalability.  (Rails should scale just fine for our needs.)

Surprisingly, while most of the developers are either excited or at
least open to the idea, there are one or two developers who are
definitely opposed to Ruby.  (OK, one to be precise:  but there could
be others who haven't spoken out.)  The objections are that Ruby is
not used or accepted enough in the corporate world, and that learning
Ruby won't help them make more money or more marketable (in the St.
Louis corporate world).  If corporations start explicitly looking for
Ruby developers they'll learn it, but not until then.

I'm not quite sure how to answer this one.  While I do think that
something is going to succeed Java, I can't predict the future.  I
can't truthfully say with assurance that Ruby will be the next big
thing in the corporate world.  It *might* be, but it might not.
Personally I'm not concerned about what the next big thing might be; I
want a language that makes me and my fellow developers happy and more
productive.  That's good for us and good for the business, I figure.
I have trouble understanding the narrow, strictly mercenary and
corporate focused point of view.  Any ideas on convincing these folks?

Thanks again.

Steve Molitor



On 4/25/07, Steve Molitor <[e-mail]> wrote:
>
> My company is thinking of moving to Ruby, and Ruby on Rails, in a fairly
big way -- maybe to the point of making it the preferred language and
framework for new applications.  We've been dabbling with Ruby and Rails in
one decent sized app and a few tiny apps.   My boss is concerned about the
issues in transitioning a mostly Java shop to Ruby -- training, integrating
with the existing Java apps, etc.  He would feel a lot better if he could
talk to folks from another St. Louis company who have made that transition.
Does anyone work in a corporate environment that uses Ruby extensively, or
know someone who does?  And if so, can we talk to you?
>
> Thanks!
>
> Steve Molitor

First, let me just briefly mention that we are moving mailing list to
Google Groups (which I cc'd on this response). So, if you could join
our Google group and direct future messages there, it would be a big
help.

I can't answer your primary question directly (other STL-RUG members
may have more direct information for you). But I can give you some
information.

Training is available both locally and nationally. The Pragmatic
Programmer's Rails Studio (Dave Thomas and Mike Clark) is probably the
premier nationally given Rails training. Locally, Object Computing Inc
teaches both Ruby and Rails classes through Washington University's
CAIT program (our monthly meetings are held at OCI's offices). And two
of our members, Jeff Barczewski and Mike Sullivan, have formed a
training company (Inspired Horizons) that specializes in Rails
training.

If you need to integrate Ruby with existing Java apps, then you
probably want to look closely at JRuby (http://www.headius.com/
jrubywiki/index.php/Main_Page ).

Finally, don't be intimidated by a lack of seasoned Ruby/Rails
programmers, just concentrate on hiring good programmers (they know
how to pick up new languages and technologies quickly). Joel Spolsky
put it very well in his essay "Sorting Resumes" (the whole thing is
worth reading):


http://www.joelonsoftware.com/articles/SortingResumes.html
If I needed to hire someone to do Ruby development, someone with
extensive Smalltalk and Python experience who had never even heard of
Ruby would be a lot more likely to be successful than someone who read
a book about Ruby once. For someone who is basically a good software
developer, learning another programming language is just not going to
be a big deal. In two weeks they'll be pretty productive.

I hope that helps... good luck and keep us posted on your progress!

Curt




.                                                                                                                                                    This message and any attachments contain information from Union Pacific which may be confidential and/or privileged.
If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this message is strictly prohibited by law. If you receive this message in error, please contact the sender immediately and delete the message and any attachments.