Well, Eric, You are not alone.  Other than a little bit politically
incorrect, I think your ranting is justifiable.

Using ROI/Risk as a reason to discourage some of the most basic thing
that a developer needs to do is just ... (not sure what word should I
used).

To give a real world example:
- It took one of the developer (who has left the company) almost two
years to get approval to use service program in our shop.  
- Why it took so long to get this new technology (which is probably more
than 10 years old by the time it got approved) approve? 
1) Management needs prove and more prove of the benefits of using
service program. 
2) Management needs revises and more revises on standard to create
service program.
3) Management worries about in the middle of the night when a program
error out, the on call program might not know how service program work
and delay the time is required to correct the problem. 


I understand that ROI is necessary when implement new/different
technology.  I'm not sure if it apply in this case.  


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DeLong, Eric
Sent: Friday, April 14, 2006 2:08 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Did we have another name change?

John,

By no means am I saying to adopt every technology that comes along.
That's not the point at all.  I just saw Michael's post, and he seems to
have understood what I'm saying...

Take a benign topic, such as modularization.  I've never met anyone that
doesn't agree that modular designs have distinct advantages over
conventional top-to-bottom applications.  There's not much to argue
about in that...  Yet these same individuals will scream long and loud
at the notion of adopting ILE, even though they know it brings benefit
to them.  They say they don't understand the technology, and have no
time to learn it, so don't
use it.   They issue the mandate to not use a technology before they
understand what they're dealing with...  It's not a problem with having
persuasive arguments, its about the decision and policy makers
absolutely refusing to consider something that they see as foreign.  

The article Scott Ingvaldson posted is a perfect example...  Thanks
Scott!
Somewhere along the line, risk aversion has become a mandate from above.
Anything new should be avoided, because it may affect the applications
in unforseen ways.  (That's fear of the unknown at work...)

I think it's fair to say that for any problem, there are probably
hundreds (or thousands) of effective solutions, and it's often difficult
to know which solution should win out.  I'll go further to state that
even though it's technically possible to write CGI in RPG/400, it's a
solution that will be difficult to develop and maintain in the long
term.  ILE serves as a better enabler for these types of applications,
but many shops are denied this approach because the shop standards and
practices have not been updated for twenty years.  Force someone to work
with ineffective tools, and you usually wind up with ineffective
results.

My original point was that such environments are hostile to young IT
workers.  We gripe at IBM for not fostering more educational offerings
to entice students into the platform, but even if they get skills,
they're rarely allowed to use them.  With no opportunities to shine,
they'll either move on (to another platform, perhaps) or they'll lose
their passion and die on the vine.....  Either way, we all lose in the
long run.  


Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Jones, John (US)
Sent: Thursday, April 13, 2006 4:08 PM
To: Midrange Systems Technical Discussion
Subject: RE: Did we have another name change?


Lou is right.  We IT professionals need to be concerned about doing what
is best for our employer.  That is what we're paid to do.  We're (in
most cases) not paid to usher in a technology revolution.

IT does not exist for IT's sake.

That's not to say we shouldn't be concerned about adopting new
technologies.  We should be.  But there has to be a business case to
change otherwise it is simply wasting company resources.

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787 F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Lou Forlini
Sent: Thursday, April 13, 2006 2:42 PM
To: Midrange Systems Technical Discussion
Subject: RE: Did we have another name change?

Eric,

    I don't know if I'm disagreeing with you or not.  Probably more with
your comments regarding older people.

    I think you could take the statement "most midrange shops adopt this
ambivalence to change", take out the word "midrange" and have it still
be true for most shops in any industry, IT or not.  I learned that
pretty early on myself.

    When I've worked at companies that were reluctant to try new
technologies, I've always found it a good idea to work up a brief
business case and present it to the boss.  More times than not, showing
how something could benefit the company (and not just my own
career) got me the go ahead for a pilot project, or for integration into
a new or revised system.  Sometimes not right away, but the seed was
planted and when the time was right I was the "go to" guy.  This
approach requires a certain level of professionalism, i.e. you need to
have the discipline to think through the benefits to the company, and
articulate them in a clear and persuasive way, versus just whining
constantly about not being able to use ILE.  Show that you're about
using technology to benefit the company, rather than using technology to
pad your resume.

    Follow that path, and quite often you will eventually work yourself
into a position to actually influence and even determine what
technologies are used at your company.  I've done it twice, ending up in
Chief Engineer type positions.

    Yes, you will run into that shop where you're hitting a brick wall
with every suggestion, and even the most beneficial changes will be
denied for whatever reason.  Once you've given it a fair shot, leave.

    Eventually, you may get to a place where you feel the desire to
explore technologies that would not necessarily benefit the company you
work for, or any likely prospects.  Maybe you can make a deal to work
after hours on your own time to learn them.  If not, maybe it's time to
start your own company.

    Part of the advantage to the AS/400-iSeries-i5-System_i is it's
longevity, it's an incredibly mature, robust, and secure operating
system.  In an industry where tossing out all your gear every 3 or 4
years (and many times the people as well) is the norm, it can also be a
liability.  That's the challenge.

    Regards,

    - Lou Forlini
      Software Engineer
      System Support Products, Inc.


At 1:53 PM -0500 4/13/06, DeLong, Eric wrote:
>No Lou, I'm talking about shutting out new talent and innovation 
>because of fear or laziness.  I'm no newbie to this platform, having 
>started with the
>S/36 while in high school.  My entire career is based on midrange, and 
>I love our platform.  But I've NEVER worked for a shop where I didn't 
>have to fight (sometimes in peril of losing my job) for the adoption of

>new technology.
>
>I know that not all shops work this way, but I believe (based on MY
>experiences) that most midrange shops adopt this ambivalence to change.

>I have felt frustrated by this again and again, and feel that this 
>attitude is killing our platform....
>
>Ageist?  Perhaps....  Again, in my experience, the senior exec(s) in IT

>sets the tone and direction of the shop.  If the tone comes across as 
>"do it the way we've always done it", then innovation is immediately
eliminated....
>
>I know my original post was worded to be somewhat offensive.  I'll 
>apologize for that, but I stand by my notion that we "professionals"
>need to be more accepting of new ideas.  We need to dazzle the young 
>talent with possibilities instead of forcing them into submission.  We 
>must accept that what we did in 1986 is not applicable to today's
application consumers.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.



This email is for the use of the intended recipient(s) only.  If you
have received this email in error, please notify the sender immediately
and then delete it.  If you are not the intended recipient, you must not
keep, use, disclose, copy or distribute this email without the author's
prior permission.  We have taken precautions to minimize the risk of
transmitting software viruses, but we advise you to carry out your own
virus checks on any attachment to this message.  We cannot accept
liability for any loss or damage caused by software viruses.  The
information contained in this communication may be confidential and may
be subject to the attorney-client privilege. If you are the intended
recipient and you do not wish to receive similar electronic messages
from us in the future then please respond to the sender to this effect.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.