Re[2]: Legacy code. Was:Dates

[Buck Calabro <mcalabro@xxxxxxxxxxxx>]

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

But I wasn't expected to be generating billable income while I went
to school.  In the workplace, every hour I spend in a manual is an
hour I'm not planning/writing code.


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

Who figures the hours/rate for the fixed bid?  The programmers who will be 
assigned  to the project, or is it based on "average" hours/rates?  This makes 
a difference because I might estimate 2 hours for a job, but a newer 
programmer may take 5 hours...

This is the crux of the question:  Obviously, the senior programmer can finish
a job quicker than the junior programmer.  How do YOU turn "junior" into 
"senior?"
Clearly, giving the junior experience is the answer, but there is a limit as to 
how
often a client will accept longer timelines.  We have many (hundreds/month) 
small
(2.5 hour average) program requests.  Very few are suited to a "programming 
team"
approach; i.e. one person does the work.  What guidelines do you use to allocate
the senior folks to help the juniors BECOME senior vs have the seniors work 
code?


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

It is a possible solution, but the state of this software precludes the
use of /COPY.  Each client has been heavily customised, so that
one can't depend on field names or sizes being common.  Would that 
I were in Utopia, and all the common functions were written as 
callable API's.  Alas, each programmer wrote her own stuff embedded
(mostly) as mainline code, a la S/36.


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

Pretty much the same here.  This leads to many false starts, and
multiple "standards" that are very slow to go away.


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

Well, one might argue that many /400 shops have code that isn't that
different from /360 RPG.  The addition of CHAIN and a few "structured"
opcodes don't make RPGIII that much different from /360 RPG.  I can
(and have!) converted RPGIII back down to mainframe RPGII with 
very little fuss because of this very fact.

However, when a programmer writes truly native /400 code, using
integrated commitment control, data queues for pseudo-parallel
processing, journaling for recovery/audit trails, distributed database
across multiple /400's: these things are not superficially different;
they are CONCEPTUALLY different.  

If I write code that takes better advantage of the platform, then I'll
be stuck maintaining that code unless we either hire another
very experienced /400 person, or grow one ourselves.Right now, 
we're hiring anybody who's HEARD of the AS/400; we can't find 
any experienced people here in Upstate NY.  This means that
our median experience level is low.  Thus, the training issue
is of huge import to us.
  

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

Right you are.  But somewhere along the line, a new feature moves from
cutting edge to mainstream to obsolete.  Witness the ascendency of
Java, vs the use of callable API's vs the use of Matching Record.  The
job market assumes you know API's, couldn't care if you know MR, and
pays a premium if you know Java.  But the old legacy code we're 
maintaining doesn't care about the changing winds of fashion.  


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

Makes sense (of course.)  The problem is that we have SO few senior
people and so MANY junior ones that it's a real economic issue to 
the company to pull the senior staff off of programming to do mentoring.
Not that we don't try, mind you!

Thanks!!!

Buck Calabro
Commsoft, Rensselaer, NY

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