RE: What counts as technically slick?

To me, one of the most appropriate of controls on this issue is "PEER
REVIEW", which is rarely done correctly, IMO. Many feel it's a waste of
valuable time, but for these types of issues (new techniques that are not
well understood by staff), it can be invaluable.  

-----Original Message-----
From: Buck Calabro [mailto:Buck.Calabro@commsoft.net]
Sent: Friday, April 06, 2001 9:20 AM
To: MIDRANGE-L@midrange.com
Subject: RE: What counts as technically slick?


Jim Damato wrote:

>My second job was for a large System 38 shop 
>where some of the "most technically competent 
>programmers" were all co-opted by one
-snip-
>The system crashed and burned when it went live 
>because the team didn't realize what their code 
>was going to do (build huge access paths
>on the fly) with production data.  
-snip-
>I'd love to hire the most technically competent 
>programmer as long as he or she knows 
>how to exercise restraint.

Jim,

There's a difference between _thinking_ one is excellent and _being_
excellent.  

Dave K said:

>When you are unavailable one day and that critical 
>business process fails, the RPG programmers 
>shall certainly curse your clever enhancement.

Who stopped all the other programmers from learning that New Thing?  

>A business needs compelling reasons to implement 
>new technologies because there are risks and costs.

There ARE costs and there ARE risks/benefits.  There should be some
technical oversight function to see that the technical staff don't go
overboard in either direction: cutting edge or obsolescence.  My original
question was "Are RPG IV subprocedures considered Technically Slick?"  I
believe that the benefits of adopting subprocedures far outweigh the cost
and risk.  There are degrees of change, risk, cost and benefit.  I use
subprocedures because I believe the benefits outweigh the costs/risks.
Clearly, the bulk of AS/400 RPG programmers don't share that view.  Why?  

>Technologies should not be implemented until 
>they can be properly supported, which means training.  
>Logically, this applies even to the level of coding
>techniques.

For the most part, we application programmers train ourselves.  Given this
reality, how much of an asset is a programmer who refuses to learn from
somebody else in house who's already done that New Thing?  You can lead a
programmer to the manuals, but you cannot make him comprehend unless he
wants to.

R. Bruce Hoffman, Jr. said:

>If I recall the discussion in question, it was about the 
>employee having skills other than just coding and 
>the importance of them.

Yup, I understand that, but the thread wandered a bit to avoiding
"technically slick" solutions because they are too complicated for the rest
of the staff to understand/maintain. That's why I started a new thread
trying to come up with some hard examples of what constitutes "too slick."
I proposed RPG IV subprocedures, but I haven't heard what the mainstream
opinion is yet.

Are RPG IV subprocedures too complicated to use for most AS/400 businesses?

Buck 

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---