Re:Legacy code. -- MIDRANGE-L

John,

>RE:    Legacy code.   Was:Dates
>>
>>1. Who pays you to learn new stuff (as opposed to writing
>>    deliverable product?)
>
>
>How many of us out there have changed jobs in the last 3-5 years?
>How many were downsized, squeeze out, Company moved, quit, out sourced, 
>and otherwised found them selves on the street in the last 3-5 years?
>
>What do these questions have to do with question #1 ?  YOU, not your 
>employer, are responsible for your career/job continuing education
>(ie Marketability). These are the days of the "commodity employee"..
>The only thing you can "offer/charge for" or "be of value because of"
>to your current/future employer is your "Marketable Skill set". 
>It is not(nor, never has been) in their "best/most economical" self interest
>to pay for your education, period.  Indeed, Education has always
>been one of the first things cut in a budget crunch.  Learning the new stuff
>always has been and always will be "worth more to the employee than to 
>the employer". (By the way, you must stay productive while you learn <BG>)

Agreed.  Completely.
That's why I personally try to learn as much as possible.  The thing is that
I'd like to raise the bar for all of us, and I'm desperate for ideas to motivate
both staff and management.


>>2. Who pays for your learning curve as you come up to speed
>>    with new techniques?
> 
>See Above.   Remember CARR's rule #1 that
>"Tact,  is the art of letting the other person have your way"  <G>

Alas, the clients know the difference between an experienced programmer
and one they're paying to be educated.


>>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..
>
>Have a shop agreement as to the future direction of a particular standard..
>Have a hit list of ways to attach the problem. 

Makes sense for future development with the caveat that we're going to
guarantee a longer learning curve because we have to expose each new
staffer to multiple ways of doing the same thing.  It's this multiplicity that
provides the inertia to keep doing it the same way as always...
 

>CARR's rule #2
>
>"If your going to the store to buy some milk,  It won't take you any
>longer to pick up a loaf of bread" 
>
>Take a browse though your source members sometime in SEU, and then window
>over say about 40 or 50,  and look at some of the "Last change date"
>of the lines of code.  These programs are "Opened up" and "Worked On"
>ALL year long.  Your shop HAS to adopt a philosphy to make small
>"benign" changes to the code while your fixing something else"..
>
>Like "Hey everybody are new standard is defining variables in the D-Spec
>as standalone fields,  Instead of on the Calc. Lines OK?" 
>So if you see a variable defined on a C-spec. while you're in 
>programs fixing something else,  Move it's definition to to the D-Spec..
>After a year or so, you would be amazed at how much your ENTIRE application
>base has been upgraded.  Also You will NEVER sell it to upper management
>or cost justify upgrading your standards as a project.  This is the only 
>way I have seen it work( in 2-3 person mom & pop shops all the way up to 
>Fortune 100 companies.   BTDT)..

That's basically how it works here.  Sadly, we have no formal standards
process.  It's doubly difficult because there is no QA staff to enforce the
modest standards we have.  Given that environment, word-of-mouth is
very ineffecient indeed...


>>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?
>
>Alot of the time,  the critically correct thing to do for the organization
>cannot be justified with a strict ROI equation.  
>
>Remember; CARR's rule #3
>
>People nearly ALWAYS buy what they want, NOT what they need.  If they WANT
>it, it's amazing the dollar and cents justifications that can be created..
>Even at the management or board room level..
>
>Lets say you have a hole in your shoe and say to yourself " I guess 
>I'm going to have to buy a new pair of shoes tonight".  Then when you
>get home, you find the TV is not working.  You say "I can't afford both"
>You will put a piece of cardboard in your shoe and take the TV to get fixed. 

OK.  I should have been more succinct.  Most programmers will jump
onto the "new idea" bandwagon on their own, whether it's a good idea
(for the company) or not.    How can you tell if it's time to give in to the
staff who want to "go for it" without an _idea_ (not necessarily strict)
of the costs/benefits involved?


>>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?"
>
>Your shop must decide which new functions or additions to be embraced and
>when.  RPGIV,  ILE,  TRIGGERS, etc. etc.  Which ones will serve you best 
>for the least?   For a transitioning shop RPGIV yes,  ILE no.  
>Start with the easy things first.   The move to the new language is a 
>perfect time to implement a new set of revised set of "Shop Standards"  
>
>Say "Starting from now on, in RPGIV programs we WILL do it this way" period. 
>When is a good time to transition?  Are you still writing for the RPGII
>crowd?  When did that change?  When did you start taking advantage of the
>RPGIII functions like String Manipulation, Named Constants, after they are
>2 years old? 5?
>They were new once,  They ain't no more....  If not today,  When???

My point exactly!  The problem comes BEFORE this: how can a green staff
decide among alternatives when they can't possible understand the 
ramifications?   Somewhere, someone has to USE this stuff.  Can we afford
to wait until someone is accidentally hired who knows about it?  No!  Because
by then the state of the software will be so decrepit that it won't be worth
bringing it up to date.  We need to take constant action to learn and use
these techniques.

How do we get that education and training?  Right now, it's hit or miss
based on the individual's guilt level (I can make up those hours I wasted
by staying leter tomorrow...)

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