From: Brian Candler <b.candler@...>
Date: 2010-11-29T19:53:48+09:00
Subject: Re: Ruby 1.8 vs 1.9

>> And you'd be surprised
>> how... stubborn non-techies can be.
>
> Not terribly. I'm more surprised how stubborn techies can be.

IME the main problems are:

* Operational. You have a whole workforce trained up to use 
mainframe-based system A; getting them all to change to working with new 
system B can be expensive. This is in addition to their "business as 
usual" work.

* Change resistance. If system B makes even minor aspects of life for 
some of the users more difficult than it was before, those users will 
complain very loudly.

* Functional. System A embodies in its code a whole load of knowledge 
about business processes, some of which is probably obsolete, but much 
is still current. It's probably either not documented, or there are 
errors and omissions in the documentation. Re-implementing A as B needs 
to reverse-engineer the behaviour *and* decide which is current and 
which is obsolete, or else re-specify it from scratch.

And to be honest, over time new System B is likely to become as 
undocumented and hard to maintain as System A was, unless you have a 
highly skilled and strongly directed development team.

So, unless System B delivers some killer feature which could not instead 
be implemented as new system C alongside existing system A, it's hard to 
make a business case for reimplementing A as B.

The market ensures that IBM prices their mainframe solutions just at the 
level where the potential cost saving of moving away from A is 
outweighed by the development and rollout cost of B, for most users 
(i.e. those who have not migrated away already)

-- 
Posted via http://www.ruby-forum.com/.