Re: Offload from the AS/400

Subject: Re: Offload from the AS/400

In a message dated 97-11-05 12:48:01 EST, atostain@crecomp.com (Art Tostaine,
Jr.) wrote:   << Guess what, the 400 is slow! >>

Hank Said;
<SNIP> 

>The applications that I have seen written for it are some of the worst
>garbage I've had to deal with, though. The competency of many of the RPG
>programmers in creating a decent system has been missing. Why? Because most
>of the programmers were "grown," not developed. [Hey, he's a decent operator.
>Let's gie him a chance to write programs.]

<SNIP>

Hank Heath


Hank 
Your dead on target.
"We have met the enemy and he is us."

I'm including something that was in my COMMON session titled
"Writing RPG for Maintainability"   
In It I tried to aproach the subject you're talking about.

Writing 'Good' new systems is only part of the effort.  If we take a 
look at any one source member and window over a ways(say W50) we
will undoubtedly see many, many, many, change dates.  

The point is; we're into lots of programs every day of the year.  Stuff
that is 10years old has been worked on and changed hundreds of times.
But how often do we make tiny, benign, cleanup types of enhancements while
we're in there?  Many times not at all.  Thats why 10 year old code STILL
looks like 10 year old code!  

(I Said it before) I strongly believe that if you go to the store for milk,
it doesn't take any more time to pick up a loaf of bread.

We should have an agenda for "Maintenance Programming" 

Like your statement Hank,  I'm sure I'll raise the ire of many readers with
this stance.

But I have seen this approach work in small shops (1-3 people) and at 
large ones(Fortune 100's) that I have worked for. 

What the result is,  after a year or two,  the Whole application base 
begins to be raised to a higher level.  (Really really really) What you 
clean up this time won't have to be done next time.  Maintenance gets 
faster, easier, and cleaner all the time.  

Take a look at a production source file and list its Min, Max, and Avg
number of unique 'source line item change dates'

Undoubtedly I'll hear many justifications/excuses why not to do this.
"You're opening your self up to new bugs"  "My management won't allow it"
I don't wanna, I ain't got the time, They didn't ask me to fix that, 
"Thats (Bobs, Mary's, whoever)'s code and I'm not fixing it"
yada yada yada.   


---
(one page out of my powerpoint COMMON pitch on why code looks like it does.)

"Most programmers spend their 40 hour week maintaining existing systems, 
instead of developing new systems. However, Maintenance programming is 
never seen as an opportunity for Preventitive Maintenance. It is only 
seen as fixing a bug or plugging a leak. The company should adopt a PM
STRATEGY that will help the systems evolve easier.

           WHO WROTE THIS STUFF ANYWAY ? and WHO REALLY OWNS IT?
NEVER ENOUGH TIME TO DO IT RIGHT,  BUT ALWAYS ENOUGH TIME TO DO IT AGAIN!
A large percent of the production programs that are running in most shops
were written by someone who does not currently work for the firm.  All of
the previous programmers nifty tricks will have to be maintained by 
current staff. The question may arise,  Who owns the application code? 
How does this relate to the programmers "DEVINE RIGHT" to creativity? The
Company(Software Owner) should demand a consistent implementation of 
it’s(the company's) standards.
        
                BETTER HARDWARE, SAME STYLE OF CODE
        The machines we are working on are being built more efficient and
faster internally every day. Unfortunately the time it takes to enhance or
maintain a poorly written program never gets faster. When the only 
criteria for moving something into production is “Well it works” we may be
just asking for trouble later down the line. Maintainability and the 
ability of the software to evolve should be our number one goal(not
performance) due to the high cost of maintenance programming and  the 
need to assimilate future language enhancements.
----

John Carr CDP
EdgeTech

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