Re: Efficiency AND Effectiveness. I just had to share this.

I totally digree with this. In my opinion the users should never be allowed on 
the system. I can't tell you how many times one of my perfectly fine programs 
has been ruined by having a user get on the system and start using it.  My 
feeling is that all my code is absolutely perfect until the users actually 
start to use it and begin finding all the bugs!
Ban all users! Ban them, I say!

:-)

Seriously...those are excellent points Larry.  I too have been in the situation 
where IT makes arbitrary descisions that, ultimatley have little basis in 
reality.  Not fun.


-----Original Message-----
    From: "Larry Bolhuis"<lbolhuis@xxxxxxxxxx>
    Sent: 8/24/05 7:22:15 AM
    To: "Midrange Systems Technical Discussion"<midrange-l@xxxxxxxxxxxx>
    Subject: Re: Efficiency AND Effectiveness. I just had to share this.
      It's what happens when IT folk think it's Their system, not the users.   
    Some years back in an AS/400 shop I was contracted to make some 
    significant changes to payroll. The company had about 1000 folks out 
    back getting payed a complicated combination of hourly, piece bonus, 
    shift bonus etc and some of the rules conflicted. So I (as a consultant) 
    get my marching orders from the IT guy.  I ask him point blank, should I 
    go meet with HR to see if this will meet their needs. He says "Nope, 
    what I have laid out is the Only way that could possibly make sense."  
    (Anybody see what's coming yet?).  Upon completion I head up to HR to 
    show them how it works.  They are shocked at how wrong it is. Virtually 
    every major decision was incorrect. Sequencing, rule selection, 
    reporting.  I had to re-write over half of the thing, fortunately it was 
    all billable but very frustrating.
    
    We IT folks need to remember who's data it is anyway.  Sure we need to 
    guide our users toward standards. We need to complain loudly when they 
    want edits removed because "They slow us down but we'll go back and fix 
    it later." (ya right) but if they insist and their data gets trashed in 
    the process remind them that it's their data.  We need to keep it backed 
    up. We need to help them with ways to use it more effectively. We need 
    to give them ideas when they're stuck but we shouldn't be cramming 
    things down their throats just because we thing something is cool, or 
    'the only way'.  Sometimes we need to let them head down a bad path but 
    be ready to help them get back. Heck, who hasn't replaced a block of 
    code with a user's requested change but left the old block in the 
    program with a comment like:  "This code was replaced for very stupid 
    reasons. So stupid in fact that it will be re-instated within a month, 
    trust me on this!"  And sure enough the users finally see the light and 
    want the old code back.
    
    We in IT need to be facilitators and leaders, not tyrants or dictators. 
    We need to listen and listen to all departments not just the loudest 
    ones.  It's not our data and the sooner we convince the users of this 
    the better off we all are.  We need to be  as they say on Mythbusters, 
    "...We're what you call Experts!"
    
      - Larry
    
    Fisher, Don wrote:
    
    >Such brilliance is not limited to the Oracle community, Steve.  I've seen
    >many examples of this type of genius during my career in AS/400 shops.  
This
    >type of thinking was endemic to IT shops in the 1970s and 80s.
    >Unfortunately, there are a few from that era that cling to that mentality.
    >
    >Donald R. Fisher, III
    >Project Manager
    >Roomstore Furniture Company
    >(804) 784-7600 extension 2124
    >DFisher@xxxxxxxxxxxxx
    >
    ><clip>
    >My wife has, for over 2 years, been project leading, for her dept. (she is
    >in finance) a project to automate their current system, not a biggy. Now
    >they had it in the USA for 12 months and not one working program, this was
    >mainly because the MIS manager did not believe you needed to talk to the
    >user to know what they wanted, I think he is cleaning toilets now. Anyways
    >the US washed their hands of it and the UK took over, so they did a little
    >talking to the user and they are now in UAT. 
    >
    >So my wife is the ONLY one on the system working at home and asked me to
    >time (what they call a report but it is a display) a report, Invoices not
    >yet invoiced, 1 country, 2,000 records, 38 seconds. All countries 51,000
    >records 2Mins 47seconds. I think we would all agree not acceptable. Also
    >there is no way that the user can ever see more than the first 5,000 
records
    >bit of a problem for the UK who had 5,500. 
    >
    >Now we come to the clever part, when they first ran this last week it
    >crashed because 6 users ran it at once, so they changed it so each request
    >was queued. Now we move from the merely clever to the brilliant. But if it
    >doesn't run within 60 seconds it is cancelled and a message is sent asking
    >the user to try again later. They decided that this info was too good to
    >only give to the requestor, everybody should get the message (merely a case
    >of lazy programming I think). Well in a meeting about this my wife pointed
    >out to the MIS manager that there could be 1,000+ users on when this goes
    >live and with the response times she was getting that everyone would be
    >getting messages all the time, and now from the brilliant to the sheer
    >genius, his immediate reaction? He started calculating how much extra disk
    >space they would need to buy to handle it!
    >
    >A shining example of analysis, design, and testing. Talk about skilled
    >professionals! I mean, you would need to take special courses to be so bad,
    >wouldn't you?  Where do they get these people from?    
    ><clip>
    >  
    >
    
    -- 
    Larry Bolhuis                   IBM eServer Certified Systems Expert:
    Vice President                    iSeries Technical Solutions V5R3
    Arbor Solutions, Inc.             iSeries LPAR Technical Solutions V5R3
    1345 Monroe NW Suite 259          iSeries Linux Technical Solutions V5R3
    Grand Rapids, MI 49505            iSeries Windows Integration Technical 
    Solutions V5R3
                                    IBM eServer Certified Systems Specialist
    (616) 451-2500                    iSeries System Administrator for 
    OS/400 V5R3
    (616) 451-2571 - Fax              AS/400 RPG IV Developer
    (616) 260-4746 - Cell             iSeries System Command Operations V5R2
    
      If you can read this, thank a teacher....and since it's in English, 
    thank a soldier.
    
    
    
    -- 
    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.