I can agree with this when there are 20 programmers. Way too many people poking around production. And if you have 20 programmers you probably have dedicated helpdesk and support staff who do have access to production data. But where you have 3 it's not practical. The same people writing the code are the people who have to investigate an issue when someone calls and says the system is wrong. If they can't access production data they can't figure out what's wrong. Which in most cases is a data entry error or the user not understanding the rules their boss required be but in the code
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Musselman, Paul
Sent: Wednesday, April 25, 2012 1:03 PM
To: Midrange Systems Technical Discussion
Subject: RE: survey: frequency of in-house coded software enhancement promotions to production
I have to reply to the comment about programmers poking the production data and programs directly.
NO! NO! NO!
My former job we used to "Load and Go" as one of our managers used to call it. We tried to be good, but there were 'events.'
My current job we originally created a 'temporary' change management system (the programs still exist and are sometimes used more than 20 years after they were created). It allowed us to keep production and test data separate, and during a promote the old version of the program was renamed "just-in-case." Technical Support handled the promotions.
Then we got involved in a major Project. Programmers complained that the technical support group was not keeping up with the promotes (which happened any time of the day (and sometimes night)). Word came down from the head of the department that programmers were to be allowed full access to the production environment. The head of operations and technical support -very- wisely got the 'word' in writing. And we turned the 20 or so programmers loose.
It was a zoo. No controls over who was working on what program; we had changes wiping each other out. Little or poor or no testing-- "It's just a one-line change." Users were tripping over changes in program function. Data barely survived intact.
Finally everyone realized that the mess could not continue. We looked over Aldon and Soft Landing change management systems and went with Aldon, mostly because it interfaced with a help desk system and we thought we might be going in that direction. Other than that, at the time both packages were pretty much the same.
We cloned libraries to make test environments, enrolled the programmers, and locked down the production environment. Once the screaming from the programmers (who could no longer touch the live environment) grudgingly stopped, and the screaming from the users (reacting to the constant changes and 'variable data') happily stopped, everyone pretty much agreed that this was MUCH nicer-- things actually got tested; changes actually worked! Users realized that fixing something 'now' is not as important as fixing something 'correctly.' Programmers realized that long nights and weekends to correct an 'oops' seldom happened (knock on wood).
So, programmers, keep your grubby fingers off the live environment!
Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx
--
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.
midrange.com
