Re: Legacy code. Was:Dates -- MIDRANGE-L

Buck Calabro wrote:
>
>Sooooo... The questions of the day to the group are:
>
>1. Who pays you to learn new stuff (as opposed to writing
>    deliverable product?)
>2. Who pays for your learning curve as you come up to speed
>    with new techniques?
Whether you are a consultant or a customer the answer is the same - you do.
Who pays for the new operating system?  Who pays for new hardware?  Again,
the answer is the same - you do.

You have to decide whether the time required to learn the "new stuff" is
code justifiable.  What happens if you decide it is not cost justifiable but
your competitors decide it is?  Your company, again whether a customer or
consultant is irrelevant, will be at a competitive disadvantage.

As a consulting firm, you have a problem beyond the expense to acquire the
new software and hardware.  You will lose billable hours while you learn new
techniques.  To miminize the lost hours, we have purchased a small AS/400
for our senior programmers to keep at home.  This permits them to "play" and
learn new techniques on their own time. It is a "win-win" situation.  We
miminize the expense to send them away to education and the cost of losing
billable hours.  They get to play at home and learn without having to travel.

With the cost of a model 150 including operating system, Client Access, PDM,
and RPG around $9,000 (less if you qualify for a developer discount), I
think every company using an AS/400 should consider buying an AS/400 for
their programmers at home.  If you amortize the cost of the machine over a 5
year period, how many free hours to you have to get from someone who
probably earns $50,000 or more including benefits to justify that expense?
Not many.

>3. How do you deal with the maintenance issues surrounding
>    several incompatible ways of performing the same function?
>    At issue here is having to re-engineer each application because
>    one can't simply pick up code designed to find the difference
>    between 2 dates and put it into another application UNLESS
>    the two applications have the same data format.

We don't re-engineer an application unless there is a reason for doing so.
If you have a Fixed Assets system you converted from a System/36 or
System/38 which you have not modified at all in the last 5 years, what does
it buy you to do anything to the system. It's not cost justifiable to
re-engineer the application.

But if you are making major changes to your order entry system, there might
be an incremental cost increase to re-engineer the system instead of trying
to patch a system which has already been patches hundreds of times over the
last 10 years.  If you consider the reduced maintenance cost of a highly
volatile system, it will probably be less expensive in the long run to
re-engineer than substantially modify the system.

As far as converting to RPG IV, before we touch an RPG/400 (or RPG III if
you prefer) program, we first convert it to RPG IV.  Then we make the
modifications in RPG IV.  Even if we to not re-engineer the program, the
productivity improvements in RPG IV can potentially save a tremendous amount
of time weighed against the minimal time required to run the code throught
CVTRPGSRC.  Of course you have to have already invested some time (and
money) in education to be able to use RPG IV.

>4. Do you have a rigorous process in place to analyse the cost/
>    benefit ratio of adopting new techniques, or do you use things
>    like "L" data types because you just want to?

We adopt new techniques when there is a potential savings in development or
maintenance times and costs.  You may also have to adopt new techniques to
stay competitive.  You may have the best A/R system on the face of the earth
but if it's still written in S/36 environment RPG II, very few people will
even consider it.

>5. How do you train all your staff in the use of the new techniques?
>    ILE is a perfect example.  I don't know ANY /400 programmers
>    who can just step into the ILE paradigm and run with it.  ILE is
>    much more OO than the Midrange world is used to seeing.  For
>    that matter, I'd love to use RPG IV in my new code, but the folks
>    who may have to maintain it after I'm gone will have a tough
>    time with it.  Should I say "to heck with them... they'll catch on 
>    sooner or later?"
>
Training someone in RPG IV is very simple.  There are many sources of RPG IV
education, e.g. Midrange Computing, News/400, COMMON, The 400 Group, and our
own seminars to name a few.  Many of these also offer books, video tapes,
audio tapes, and computer based education.  There are also a number of
companies who offer education in their offices locally and at customer sites.

The time required to use RPG IV effectively is minimal.  A one day seminar
will give you the basics you need.  You could also use books, videos, etc.
Learning ILE is another matter.  If you have only an RPG background, it will
take you substantially longer to effectively use ILE.

There are many ways to make the time to learn RPG IV and other new
techniques.  Keep an RPG IV book in the bathroom.  Read it when you travel
(hopefully as a passenger).  Spend just an hour a week learning something
new.  It is amazing what you can learn at the end of 6 months.

The extent to which you do learn to take advantage of new capabilities will
make your company more competitive and you personally more valuable to your
existing employer or to a new employer.

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---