No Subject -- MIDRANGE-L

with UUCP id WAA01158 for MIDRANGE-L; Mon, 15 Sep 1997 22:07:03 -0500
Date: Mon, 15 Sep 1997 22:52:06 -0400 (EDT)
From: DAsmussen@aol.com
Message-ID: <970915225002_995157878@emout10.mail.aol.com>
To: MIDRANGE-L@midrange.com
Subject: Re: Re[2]: Legacy code.   Was:Dates
Sender: owner-midrange-l@midrange.com
Precedence: bulk
Reply-To: MIDRANGE-L@midrange.com
X-List-Name: Midrange Systems Mailing List (MIDRANGE-L@midrange.com)

Buck,

Some more thoughts, since there have been so many replies...

In a message dated 97-09-15 16:36:51 EDT, you write:

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

Ah, but you were expected to be learning skills that generated MORE income
than what you made working at the grocery store during high school!  You're
wrong about hours spent in a manual.  Researching alternative (preferably
BETTER) techniques is PART of your design work, therefore billable.  While a
client can expect a reasonably competent professional to do their work for
them, they CANNOT expect that professional to know EVERYTHING.

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

A "senior" figures this, factoring in the skill-set of the person to be
assigned.  He also shows that person how he arrived at the figure, so they
start learning estimating skills themselves.  It is important that you do not
let a "junior" perform their own estimates at first, because this will only
result in overruns, low opinion of the "junior" both in-house and by the
client, and bad client relations for your company as a whole.

We have two policies on fixed bid.  1) NEVER-EVER DO THEM UNLESS YOUR LIFE IS
IN DANGER.  2)  IF YOUR LIFE IS IN DANGER, JUST DIE AND TAKE IT LIKE A MAN
:-).  Seriously though, fixed-bid is the fastest way to lose money in this
industry, or your company if it's a large job.  The only accurate method I've
found for bidding is to take your worst-case scenario, add 25%, and then
double the result -- you MAY end up making money on it.  If the client
demands fixed bid, they're going to have to pay for it and realize that they
COULD have come out cheaper on a time and materials basis.

YOU have to give a little as well, and we offer a +/- 20% guarantee on all
fixed-bid work.  In other words, if you underrun the client receives a refund
of X% that we were under.  In an overrun, the client will never pay more that
20% over the original estimate.  We also offer employees a multi-level bonus
for all billable hours over 40, maxing out at $5/hour less than what we're
billing the client at 60 hours.  The latter ensures that the employee gets
overtime for weekend work.  The employee is also not docked his/her "hours
over 40" for work done supporting the office, packages, or education time --
that way you don't come back from COMMON and NOT receive your bonus for doing
an OS/400 upgrade for a client that next weekend.

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

Whenever possible, team the "junior" with a "senior", especially if you're
putting the "junior" into an account that's ordinarily the domain of the
"senior".  Have the "senior" orient the "junior" to the site, explain where
things are and why, explain the file structure, and point out the "really
nasty" programs.

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

Hence the need for the "toolset" that I mentioned in my other post.  If you
create a date conversion API that uses an externally described data structure
that ALWAYS has the same field names, then you can move your disparate field
names into it at ANY site.  When time allows, strip out the mainline code and
replace it with the API.  Perform the latter when you are under estimate.

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

That's why you NEED in-house standards!

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

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.

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

Yes, but these things have been available on the mainframe for quite some
time as well (due to the database).  When I helped bring a pharmaceutical
company from the /370 to the /400, they were quite chastened by the
difficulty of implementing commitment control on the AS/400.  They looked at
them like WE look at file handling for C -- "Dang, don't we have an operating
system to do this?".

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

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!

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

Nope, and that's why they need YOU.  They can't hire someone on a perm basis
that WANTS to work on this stuff.  That's why YOU need to start integrating
the new stuff "under the covers" at legacy accounts.  Unless you're in a
controlled environment, the client doesn't care HOW it works -- just that it
DOES.  You should also start charging a premium for folks that refuse to move
from 5360-63 platforms -- your people don't want to work on them and they're
about to start demanding A LOT (two words) of your time.

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

Some of the above suggestions should help with that.  You should also make
sure that you have an agressive compensation program in place to stem
attrition of your senior people to other companies.  Things are getting
CRAZY!  My current primary client just lost TWO mainframe DBA's because they
knew IMS (Y2K) -- 20% salary increase, an $8K signing bonus, profit-sharing
bonus, AND a promise of a 10% increase next year!  THIS is LUNACY!!!

HTH,

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

"Quitting smoking is the easiest thing in the world to do.  I've done it
myself thousands of times." -- Mark Twain


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