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

Buck Calabro wrote:
> 

> Today seems like a good day to open a can of worms...
> 
<<snip>>
> 
> Sooooo... The questions of the day to the group are:
> 
> 1. Who pays you to learn new stuff (as opposed to writing
>     deliverable product?)

The same people who paid you to go to school....nobody.

> 2. Who pays for your learning curve as you come up to speed
>     with new techniques?

Fixed price bidding and programmer payment.  We bid a fixed amount, the
programmer gets paid a fixed amount.  This way the programmer gives
themselves a 'raise' (fewer hours/same pay) as their skill increases. 

> 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.

This can be handled with /COPY use and each 'standard' in it's own
library.  ie: application #1 uses a /COPY member which performs date
validation called VFYDATE.  Application #2 also uses a /COPY named
VFYDATE but with a little trick of library lists, each application calls
the appropriate /COPY member into the program.  It's not pretty, just
one solution.

> 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?

No.  The designers hash out the ramifications and toss a coin. :)

> 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?"

If we always coded so those less capable could understand it, we would
still be using 360 RPG.  If the client receives a benefit ie: overall
cost reduction of project, those that follow will either improve their
skills or get culled from the herd.

> 
> I'm REALLY interested in hearing what other shops have to say on
> the matter or adopting new techniques!
>
Wholesale shifts in design approach are never taken lightly.  Just
because a feature becomes available doesn't mean we HAVE to use it. 
Generally it boils down to a compromise between both short and long term
economics.

Just between you and me (nobody is listening, right?) we may perform
some learning curve trials on a custom addon to our applications to see
if anything jumps up and bites us.  They is usually some project that
crops up with a far enough delivery date to do a little experimenting
on.  (Refer to questions 1 and 2)  

JMHO

James W. Kilgore
qappdsn@ibm.net
+---
| 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
+---