× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE:Legacy code
  • From: Buck Calabro <mcalabro@xxxxxxxxxxxx>
  • Date: Tue, 16 Sep 1997 18:19:56 -0400

Dean, 

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

There's a limited amount of research that one can bill, but your point is
well taken.

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

Good points.  When the environment consists of the "seniors" buried
in "real work" (not my definition...) then the "juniors" are left with too
little guidance.  It's a tough hole to climb out of...


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

I'll have to pass this along to management as a real life example of
what I've been talking about.  Nobody seems to believe me.  The client's
LOVE fixed bid (easy to budget)  Management is worried about overruns, 
but the thought is that we can generally make out OK.


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

We do that, but it's too abbreviated to do as much good as I'd like.


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

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


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

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.


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

Yup.  That's the point I was (feebly) driving toward:  A design that takes 
advantage of the entire platform is much more work than merely knowing
the RPG opcodes.  There's much more training involved; training that
doesn't come easily or quickly.

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

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.


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

I can slip in evolutionary type stuff into existing apps easily enough
(like structured RPG opcodes) but I can't re-design the stuff with
modern methods.  It's those modern methods that the new folks need
to see more than anything else, I'm afraid...


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

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

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.