RE: What counts as technically slick?

I agree.  Maybe I should start a thread about "What passes for technically
slick?"

These folks designed a system that was really cool, but they didn't
understand the full technical and administrative impact of their design.
They also were in a great hurry to be the first to try something new.  What
they came up with was an early AS/400 and RPG version of an SQL based
system.  If someone had known how to tune the database for OPNQRYF, and size
the hardware for it they might have actually been successful.  The system
design was far and away beyond what most of us were writing, but it either
wasn't ready or wasn't finished.  Proper technical management might have
harnessed their talents for the forces of good instead of evil (or at least
chaos).

A couple years ago I attended a presentation of Lawson's first generation of
web-enablement (then on Domino) at CUE.  One of our Directors kept trying to
ask (in all seriousness) why we would want to implement it.  Because the
development team was running the presentation the folks at the front of the
room repeatedly gave different answers that translated back to "because it's
really neat."  It was quite funny to watch as one of the Lawson Client
Manager realized what was happening and bolted out of the room in search of
someone from Lawson who could explain the business needs served by their
slick new technology.

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