• Subject: RE: Legacy code.
  • From: Buck Calabro <mcalabro@xxxxxxxxxxxx>
  • Date: Mon, 15 Sep 1997 14:47:46 -0400


>Buck Calabro (mcalabro@commsoft.net) wrote:
>>Today seems like a good day to open a can of worms....
>My heart soars like a hawk. :-)  It's quite a big can, Buck, so I think
>I'll just dip in on a few of the juicier morsels..
>>   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..
>That's sad. The value of your staff is steadily decreasing and that
>includes their billable value. The best staff will get pissed off and
>move to more enlightened employers, compounding the problem. The clients
>will then get fed up with the quality of the remaining staff and start
>to look elsewhere. This is a high-tech industry. Whether you're a
>software house, an MIS department, or an independent contractor you must
>have sufficient in the budget for staff development..

Agreed (thus the questions...)  The problem is the relative experience level
of our staff.  Because we've experienced incredible growth the past few years,
we've hired many "resources" whether they're experienced or not.  We write
custom software, which compounds the problem.  We require x billable hours
per person to survive as a company (not to mention prosper!)   Obviously, if
the company "pays" for education (with hours invested, course costs, etc.)
then those expenses must be recouped.  Thus the question of who pays...

>>   Who pays you to learn new stuff (as opposed to writing
>>    deliverable product?)
>>   Who pays for your learning curve as you come up to speed
>>    with new techniques?
>The client pays for everything, of course. That's what clients are for..

This is the obvious answer, but they don't much like it.  It's very hard to
disguise a beginner to a client when the programmer has to talk to the
client to get the details, etc.  There's a big difference between the client
knowing that the invoice at the end of the month contains buried charges
for overhead, and personally experiencing the fact that they're paying
for one of our programmers' education.

>>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?"
>No, of course not; you must stick to your shop standards. However, the
>standards get revised from time to time, don't they? Why not plead and
>beg to be the chosen one who develops the new shop standards for using
>ILE? The shop is going to need them sooner or later. That way you'll be
>given the time and training you need to get to grips with it. Not only
>will you be the blue eyed boy for actually volunteering to do
>"documentation" but you'll also be well placed as the shop's ILE guru
>when the first project gets underway, as it must eventually do..

We don't have hard and fast standards; too many juniors, too many 
clients, too little time.  There's no tradition of having a project leader
who gets educated first, then educates the others.  It's learn-as-you-go 
for each individual.  Not that everyone works in total isolation; far from
it.  If someone needs help they ask a more senior person; but they feel
guilty about it (taking away billable hours...)

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

This thread ...

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

This mailing list archive is Copyright 1997-2019 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].