From: Robert Klemme <bob.news@...>
Date: 2005-06-04T18:15:25+09:00
Subject: Re: Building a business case for Ruby

Joe Van Dyk <joevandyk@gmail.com> wrote:

> I work for <insert huge company that makes really big expensive things
> here>.  We have "computing standards" that define what's allowable for
> usage internally and externally.  Technology evaluation boards, etc.
>
> Here's an evaluation of Ruby:
>
> "XXXX already has Product Standards for Python and Perl as
> Scripting/Dynamic languages. And for Java as a full programming
> language.

This indicates that for every supported technology there's quite some 
overhead in this company.  That might eventually be the reason that will 
prevent introduction of Ruby unless you can suggest huge benefits with Ruby 
on board.

> Ruby offer nothing significant not found in these XXXXX Standard
> languages, and an addition language just adds variation."
>
> Boo, I say!  Boo!

I'd be sorry, too.

> We've got mountains of unmaintainable perl stuff here, and I haven't
> really seen much in Python.  I'm in charge of developing some new
> software and would like to use Ruby.  Actually, the software is
> finished (very quickly) and I just need to get Ruby on the allowed
> list.  :(

This reminds me of the Dilbert catoon where boss wants a plan for some 
change to do.  Dilbert does it clickedyclick while they are talking.  In the 
end boss says, "now all I need is the plan".

> Help me out here guys!

Others have posted a lot good arguments in favor of Ruby.  Although I too 
would certainly do Ruby rather than Perl there might be good reasons for the 
company to not introduce Ruby.  The time it takes to write a program in any 
given language is just one factor.  These might be show stoppers

 - cost to train people for the new language

 - maintenance of an infrastructure for this new language (updates, 
development environments...)

 - cost to integrate legacy code / applications.

IMHO you can increase your chances of introducing Ruby by

 - providing a sound strategy for intregration (and maybe later phase out) 
of existing stuff

 - demonstrate the easy of access to documentation (ruby-doc) and existing 
code (RAA, rubyforge...)

 - presenting examples of unmaintainable legacy code that would have to be 
rewritten anyway (and that ideally would benefit from being rewritten in 
Ruby)

 - generally if you not loose sight of the environment where you want to 
plant Ruby and considering the fincancial effects.

I wish you luck nevertheless.

Kind regards

    robert