Re: Legacy code -- MIDRANGE-L

Buck,

In a message dated 97-09-16 22:38:35 EDT, you write:

<<snip>>
> >The aforementioned lower billing rate and understanding with the customer
>  >will help with the speed of development deficit.  Where possible, "bank"
>  >projects that aren't of immediate need at a given client site so that the
>  >"senior" can spend a half day helping the "junior" get all projects done
at
>  >once rather than having either spend the full day there.  For example,
save
>  >up 4-5 2 hour projects at client X, and have the "senior" and the
"junior"
>  >work together resolving them.  This will also reduce your "down-time" due
to
>  >travel!
>    
>  This was one of the things that gave me the shivers when I started.
>  There's very little planning when it comes to deciding which requests
>  to work on first.  One can deliberately choose a batch of easier
>  projects to give to a new hire, to make their orientation easier.  As it
>  is now, the client sets the priorities without much input from our 
>  management.  This means the junior gets a mix of complex and simple
>  stuff all at once.  Bummer.

Especially given your described growth, this planning needs to start NOW!
 Long-time clients that were used to you showing up right after they called
will have to be retrained to the realities of your company as it stands
today.  You may lose a couple, but most are understanding when it comes to
scheduling difficulties.  I didn't mention that we also have a policy that
the client pays travel time if they haven't booked a full day's work.  After
a couple of jobs where they pay six hours for four hours worth of work, they
become more amenable to trying to assemble eight hours' worth before they
schedule.  The client is, of course, not docked travel if we estimate eight
hours and it only takes six -- the employee just gets to go home early!  The
client is also not docked if two people are sent to knock out an eight hour
job in four.

>  <snip about the need for standards>
>  I think it's a given that we NEED standards; how do you convince
>  management to enforce them?

Show them that they're losing money if they don't.  Revenue attrition seems
to be the only thing that attracts their attention, ESPECIALLY if you are
unfortunate enough to have management with no technical skill set (or HAD
one, but worked in a shop where they weren't expected to perform to schedule
and delivered every time).

<<snip>>
>  >Yes, but left-hand indicators only complicate maintenance at a later date
on
>  >the AS/400!  A modern RPG program not setting display and print file
>  >attributes should only use TWO indicators -- one for file hits and LR.  A
>  >WELL-WRITTEN example of the same might use three or four to elegantly
>  >handle I/O problems..
>  
>  I agree, but the point was that we've inherited too many of these old
style
>  programs.  It's a hurdle that beginners are forced to leap because we
can't
>  readily retrofit.  New mods made by juniors tend to work like this:
>  Find another (old style) program that has a similar function
>  Copy the (old style code) bits that we need
>  Insert the (old style) code
>  Compile, test, debug ad nauseam.
>  They rarely get to use new code because they're too stressed to hit the 
>  books, and there are too few seniors to oversee each request.

That's where the company toolset comes in.  Quit copying the "old style" code
and START copying the "new style"!

<<snip platform-specific training stuff>>

>  >They're NEVER going to get experienced unless they're exposed to that
>  >"advantageous" code and forced to decipher what it does.  I understand
about
>  >the personnel problem.  We have the same here, and Al's been griping
about
>  >NYC for YEARS :-).  I hear Minneapolis is a HOT-BED of AS/400 talent!
>  
>  That's certainly one way to look at it, but I worry about the after
effects:
>  If I design an application (not just one program) that uses commitment
>  control and embedded SQL, it's not apparent to someone who has taken
>  an RPG training tape course what is happening "under the covers."
>  When they try to add a new program to the application, they'll get record
>  locking errors and lock level mismatches and all sorts of unpleasantness.
>  I'm not worried about putting a SELEC/CAS construct in an RPG program:
>  they can see the entire effect of that bit of code right there: there's no
>  "under the covers" action that they need think about.

No, it's not apparent.  But that's how _I_ learned embedded SQL -- someone
else started writing in it.  Commitment control can be reduced to a list of
less than 10 rules that someone starting out needs to know, with emphasis on
how to handle it in an ABEND situation.  The locking stuff is going to be
there even if you're NOT using commitment control.

<<snip>>

>  Dean, I value your comments quite highly, and I am going to try to make
>  some changes at least with the crew I work closest to.  I may not be able
>  to sway corporate management, but any advance is better than none at
>  all...

Thanks.  I'm afraid that if you cannot convince management at the corporate
level to make some fundamental changes, your company may be doomed to "death
by growth".  "Your crew" is a start, but what do you do when "your crew" gets
trained and taken by another company because Management doesn't adequately
compensate them?  You cannot be expected to pay them out of YOUR OWN pocket!

Regards,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@AOL.COM

"The game of life is not so much in holding a good hand as playing a poor
hand well." -- H.T. Leslie
+---
| 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
+---