RE: Legacy code. -- MIDRANGE-L

Dean,

>Buck,
>
>In a message dated 97-09-12 17:31:57 EDT, you write:
>
><<snip>>
>> Today seems like a good day to open a can of worms....
>
>And you indeed have!
>
>>  Lance mentioned that "we set the standard before RPG could handle 
>>  null dates and we have not revisited the subject yet."  Our company
>>  has a LOT of legacy code: stuff that was written when RPGIII was 
>>  new, and there were more S/36 programmers than AS/400....
>
>Why have both of you waited TEN years to upgrade your standards?

Legacy code already exists; it was here before me, and I suspect 
it'll be here after I'm gone.  Some of our clients are still on V2 and
cannot handle anything much more complex than OPNQRYF and
commitment control.  It's not my fault, I swear!  I read about it, but
I can't put it into action!  (Put another way, I'm painfully aware of
my shortcomings...)


>>  I've followed the debates over the "L" data types very closely,
>>  but we will probably never use them.  Why?  There's no way 
>>  our clients will pay us money to re-do the database and the
>>  supporting code simply to use the "L" data type.  They will
>>  get no additional functionality for the expense they would incur..
>
>No, but there's nothing stopping you from using them in all future
>development..

Except the fact that we have NO code in RPGIV (it's all legacy)
and one person who has ever used "L" data fields (me).  I can
realise your outrage when you hear about stuff like this, but
I suspect that this is common here in the Northeast US.  High
taxes, regulatory excesses and decaying infrastructure have 
left many businesses here acutely conscious of costs.  The
bottom line is that there is little emphasis from management
to keep current, as long as the billable hours flow.

My worry is that by the time the billable hours drop it'll be too
late to teach the staff about the new stuff.


>>  The other side of the coin is to implement them as we write
>>  new applications.  That's not quite so hopeless, but there are
>>  significant obstacles even there:
>>  1. Education.  Few on our staff have the luxury of taking the time
>>      (and billable hours) to learn about new developments like ILE
>>      and "L" data types..
>
>If you are taking this attitude toward education, then your company is doomed
>to failure along with the 7 (now nonexistent) consulting companies on MY
>resume.  If your staff are generating an average billable rate, then you are
>FOOLISH not to provide them additional education -- regardless of billable
>hours lost.  If management is greedy enough to keep THAT close a tab on
>billable hours, I'd personally find another job (Lord knows I should have
>done that at least seven times previously).  If your company is one of those
>"low-ballers" out there that hurts the rest of us, then you DESERVE to go out
>of business.  You will NOT be able to keep decent employees without a
>commitment to education..

I'm on your side of this argument.
I personally keep up with as much of the trade stuff as I can get.  My dilemma
is to try to spread the wealth, if you will, without jeopardising my own
position.  If I take too much time "teaching" then my billables drop.  THAT gets
me noticed in a hurry!


>>  2. Maintenance.  Do we REALLY want to implement yet another
>>      way to handle dates?  We already have: Julian (YYDDD),
>>      Gregorian (MMDDYY), Inverted Gregorian (YYMMDD),
>>      Inverted Gregorian plus century digit (CYYMMDD - Synon),
>>      Inverted full Gregorian (YYYYMMDD) All thanks to legacy
>>      code.  We have been focussing our maintenance efforts on
>>      using the YYYYMMDD form to store dates in the database
>>      because it is "natural;" Queries, EIS tools, Data warehouse
>>      tools, data interchange are all easier.  Any variety of RPG
>>      (or any language) can read this form and understand it..
>
>Sorry, but Lillian is now the standard.  It's not a question of WANT, it's a
>question of NEED.  Yes it's a pain in the gludious maximus, yes it provides
>no perceived value to the client, and yes we NEED to do it!

But you can see why there'd be resistance to learning "date handling method
number 7."  Any new technique seems to have 2 polarised groups:  "Jeez, 
not ANOTHER way to do the same thing!  What's the difference?"  And "I'm
going to use this new ODBC no matter if it takes me all week.  They can
go to the devil if they want to stay in the dark ages..."  I'm looking for the
in-between area...


>>  Sooooo... The questions of the day to the group are:
>>  
>>  1. Who pays you to learn new stuff (as opposed to writing
>>      deliverable product?)
>
>DAMN IT, YOUR COMPANY DOES!!!  If you're lucky enough to work for clients
>like I do, then sometimes the client pays.  Otherwise, your company NEEDS to
>recognize the value of education and pay for it THEMSELVES.  I'm sorry, but
>I've attended EVERY COMMON conference that I could since going independant,
>and have occasionally paid for my contractors to go as well..

We work for clients too.  The client pays, but they're not real happy about it. 
 A
typical exchange "You're billing me for HOW many hours?  Why did you put that
new guy on MY project?  It would have taken Ms. Guru half of that time!  I don't
pay you for on the job training: I pay you for work delivered..."  Sigh.


>>  2. Who pays for your learning curve as you come up to speed
>>      with new techniques?
>
>YOUR COMPANY!!!  Doggone it, can you not see that a Synon-Certified employee
>can bring in $10-50/hour more than a traditional RPG programmer?  Education
>pays for itself!

Not while the student is being educated.  And who will support the old stuff 
once you've paid to transition that staffer to Synon?  Now you're another
body short, in a staff that is too thin already.  These are obviously management
arguments.  


>>  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..
>
>You create a standard date API, install it in all of your client sites, and
>force all of your employees to USE IT..

And retrofit the old database and software?  For free?  This is so thorny
an issue.  I'm in favour of a standard API, but the best I could do was
convince management to commit to was to retrofit if the occasion arises;
new dates in the database are to be YYYYMMDD, when we run across
other formats, we make a log so we can go back and fix them later, when
the clients decide to approve Y2K fees...


>>  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?
>
>Large companies do.  Small ones must analyze the benefit to their company in
>the area of operation.  If you're a consulting firm, new techniques increase
>your overall value to the community.  If you're a software provider, then you
>MUST analyze the benefits of using new techniques against the range of OS/400
>releases that you plan to provide support for..

There's a fear of committing to a new technique before fully understanding it's
ramifications.  I'm not talking about using SELEC/CASxx; I mean things like
embedding SQL in RPG and journaling and ILE.  It's not easy to make decisions
based on marketing brochures...


>>  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?"
>
>The same way we used to do with CASE before it failed in its promise.  Hire
>knowledgeable professionals to help you with it, and glean all that you can
>from them during their term of employment.  I don't know what you mean by
>"the folks who may have to maintain it after I'm gone", but you have a
>RESPONSIBILITY to bring folks at a client site up to speed on what you've
>done.  Yes, you should say "to heck with them...they'll catch on sooner or
>later", and you'll be doing them a favor by forcing them to do so..

What I meant was that I will not personally maintain every piece of code
I've ever written; that there will be others who will be in there.  If I'm the
only person at my shop writing real ILE stuff, what do you think the chances
are that someone else will know what binding directories ARE much less
which one to use...

Our clients get our source code, but most of them do not make mods; they
leave it to us.


>>  I'm REALLY interested in hearing what other shops have to say on
>>  the matter or adopting new techniques!
>
>Most take a cautious stance, and THAT is advisable.  I work primarily for
>Fortune 100 companies, and have both a WIN 3.1 and a WIN NT computer to
>support them.  Most of my clients waited on WIN '95 and determined it to be
>an unacceptable business platform.  Despite the hype from IBM, most are
>waiting to see if JAVA becomes a viable BUSINESS development tool.  A few
>adopted CASE, and are now paying the price.  Consulting firms CANNOT afford
>to wait on ILE -- it is rapidly becoming the standard (above JAVA), and more
>companies demand it every day.  You should be cautious, but you should also
>be AWARE of new techniques....

I completely agree... that's why I keep up with the trade pubs, etc.  This list
is helpful in that regard.  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
+---