Re: Legacy code. Was:Dates -- MIDRANGE-L

Buck Calabro wrote:
> 
> >>
> >> 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.  

Sure you were, you just didn't do it while you were "in class".  Unless
of course you went on a full scholership and someone else footed your
living expenses.  Some of us worked our way through school so the idea
of getting an education and working at the same time just seems like the
norm.

Companies that have the economy of scale may be able to fund in full or
part additional seminars or classes but the rule of thumb, whether a
staff member or working for a software house, is that educational
budgets are very tight.  I can't think of any profession were the
potential for income is as high as in this field where it is not only
expected but prudent for you to take some of that hard earned money and
invest it in your own marketability.

> >> 2. Who pays for your learning curve as you come up to speed
> >>     with new techniques?
> >
> >Fixed price bidding and programmer payment.  
> 
> 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?
>
All jobs are bid at the senior level.  All programmers receive a piece
of the revenue.
IE: 2 hours @ $80/hr billed = 2 hours @ $40/hr paid.  If you are senior,
you earn $40, if you are junior you may take 4 hours and in effect earn
$20/hr.  The nice part about this is that a persons pay is DIRECTLY
related to their productivity and NEVER has to ask for a raise and go
through the anguish of trying to justify it, nor can any person sit in
judgement and deny someone what they deserve.  Therefore there is a
built in incentive for a person to increase their productivity.  

Side note: If a junior person makes a statment of deliverability to a
client that is a contract.  If that estimate is wrong, your company
could face a nonperformance suit.  Fot this reason we make it very clear
to the client and staff that junior personel are NEVER to provide
estimates.
> 
> 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?
>
Some projects are very timely and do not allow us nor the client the
ability to put too green of a person on a particular project.  But the
2.5 hour projects are perfect for the junior staff.  BTW, each client
has a senior person assigned to them and even 2.5 hour projects are
reviewed and managed by that senior person.  This person is the DIRECT
contact with the client and it is known to all parties that a junior
person is performing the actual work.  The estimating time, impact
analysis, test creation and final acceptance is performed on a time &
materials basis by that senior person.  Technical services have their
deliverable and scope well defined before anyone starts on the program.
 
> >> 3. How do you deal with the maintenance issues surrounding
> >>     several incompatible ways of performing the same function?

> >This can be handled with /COPY use and each 'standard' in it's own
> >library.    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.  
>
This is an all too common problem with home grown code.  Purchased
applications are usually a little more standardized.  When we encounter
such a project, we will as a standard course of action create /COPY
members for all file I/O specs, data structures, set, read and chain
routines and start using them.  It's a part of our service.  With a
scan/replace of the remaining program it's not an overwhelming task. 
These would match the external definition of the file and we can write
native code and the calc specs would work with either the program
described or external definition.  It's just part of the bid.  The
person doing the estimate takes a look at how bad the code is and makes
the bid accordingly.  BTW a /COPY called VFYDATE does not have to be the
same routine at each client site.  
> 
> >> 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.
>
I should have clarified that the designers as a whole hash it out.  It
is not left to any individual.  If any individual wants things their way
they can start their own business.

> >> 5. How do you train all your staff in the use of the new techniques?
> >
<snip>

> 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.
>
Personally I'm starting to get the feeling that someone in your company
just can't say no to a client request.
Sometimes a company that is running old code just has to stand in line
and wait, or just bite the bullet and pay a higher price so your company
can hire experienced people.

If they threaten to take their business elsewhere, remember that your
competitors are pretty much in the same boat. Maybe having your
competitors bogged down with a client base requiring support for S/36
style systems may be a good competitive move. ;-)

I can't imagine there is more of a shortage of manpower in upstate NY
then the remaining US, there just aren't any willing to move there at
the price your company is willing to pay (which probably is a reflection
of the price they charge).  There is an old business rule that if your
services are under high demand, you're charging too little.  The client
knows they are getting a bargain for their requests so the requests just
keep rolling on in.  If your billing rate went up, some projects just
wouldn't seem as important to the client any longer.  Therefore they
invest in more meaningful projects.
> 
> 
> >> I'm REALLY interested in hearing what other shops have to say on
> >> the matter or adopting new techniques!
> >>
> >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.  But the old legacy code we're
> maintaining doesn't care about the changing winds of fashion.

Then it should either be replaced or brought up to date.  I know it's
difficult to convince clients to do this, but it really is to their best
interest to make that decision.  But even rock solid applications do not
REQUIRE to be state of the art.  

Maybe you could have your clients take a look at the original
development costs vs the ongoing maintenance costs.  See what the
numbers point out.  You may be able to turn the next two years of 2.5
hour fire stomping jobs it a wholesale rewrite and put all of those
juniors to work on some REAL code!

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

How about the senior staff doing project management and making mentoring
a part of that function?  At one to two hours per day per junior member
with allowances for other duties a senior person should be able to
handle at least five maybe six junior members.  Remember that this time
is billable to the client as part of the project. The senior person is
still responsible for the deliverable. If your ratio is higher than that
you may want to brush up your resume'.  Your employer may not survive
much longer.

Could you give some ratios on senior to junior and client count?  Don't
name names, just wondering how bad off your situation is.

> 
Good luck.

P.S.  I spent some time on your side of the fly over and sure do miss it
in the fall.  IMHO it's the prettiest place in this country this time of
year.
+---
| 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
+---