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
midrange.com
