Re: survey: frequency of in-house coded software enhancement

We're a 2 programmer shop. We try to put any changes that could actually
hurt or confuse anyone into a test library first and put that in the
library list. When that proves ok we permanently implement it. When we
implemented IBM Geographic mirroring, we had to take control of our library
list via job descriptions. We wrote a system which mostly has these
options.,

11. HA02 MAINTAIN INITIAL LIBRARY LIST
12. HA03 MAINTAIN NAMES OF LIBRARIES CONTAINING JOB
DESCRIPTIONS
13. HAJOBDUPDA UPDATE ALL JOB DESCRIPTIONS WITH INITIAL LIBRARY
LIST
14. HAJOBDCHG UPDATE 1 JOBD WITH INITIAL LIBRARY LIST

We can use option 11 to add a test library our database file containing the
initial library list.
Then use option 14 to give it to some appropriate test users. (They need to
sign off and back on.) When they have proven it, we use option 13 to give
the new library list to everyone. If we do find an issue it is easy to take
the test library out of the list and put it back the way it was. When the
changes have been in production for a while, we have a system which copies
the test library to production, making copies of everything it is going to
replace before replacing them. Works well for a 2 person shop. Probably
not if you had 20. We also added an option to our programming environment
that whenever you access a program in edit mode, makes a text copy of it in
the ifs first. Poor mans change management I guess, but we haven't lost
anything, made anyone unhappy or done any significant damage in 20 years.
I do remember 1 bad morning back on the S36 :) .

message: 6
date: Wed, 25 Apr 2012 14:37:49 -0400
from: John Yeung <gallium.arsenide@xxxxxxxxx>
subject: Re: survey: frequency of in-house coded software enhancement
promotions to production

On Wed, Apr 25, 2012 at 11:03 AM, Alan Shore <ashore@xxxxxxxx> wrote:

Yikes
So your method is "LIVE" testing.

As Rob indicated, there is nothing about "compile directly to
production" which means "don't do any testing". We do testing in
nonproduction libraries before making live changes. My point is just
that when we're ready to put something in production, we just do it.
There isn't a formal schedule.

How large a change are you allowed/willing to do?

We're basically allowed to make whatever changes we feel are prudent.

What do you do if you have to introduce a new process
that the system presently does not have?

Whatever users are affected will be involved in the testing and
deployment. (About 99999 times out of 100000 it is they who are
requesting the change anyway.)

Rob, I appreciate that you pointed out the myriad possibilities for
robust development and testing that isn't ruled out by what I said. I
completely agree with you in principle.

However, I have to admit that in my case, we don't really have what
the software engineering discipline would call "robust development and
testing". As I said, where I work, we rely almost entirely on the
abilities and judgment of the programmers, and have almost no *formal*
processes in place.

I know there are some in IT who believe it is always better to impose
"proper" IT practices on any company of any size and in any situation.
I agree it's safer. I don't know that it's always better or that
it's always even feasible. Money and time are big obstacles at some
companies, and culture is probably an even bigger one.

John