RE: Offload from the AS/400

John:

Boy, you've hit the nail right on the head as far as I'm concerned.  You
are sooo right that if we make small improvements everytime we're doing
maintenance to an existing program (and add documentation), over time it
does raise the level of whole systems.  Been there, done that!!!

Dave

>----------
>From:  John Carr[SMTP:74711.77@compuserve.com]
>Sent:  Wednesday, November 05, 1997 11:18 PM
>To:    Midrange-L
>Subject:       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
>+---
>
+---
| 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
+---