RE: Programming a trigger audit in ILE

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

>>>How many times have we fixed a program, and then not 
>>>really understood why or how we fixed it??  
>>
>>In my case, never.  If I don't understand the 
>>code then I don't put it into production.

>Don't break your arm patting yourself on the back!   I never 
>said I didn't understand the code, I just said eventually 
>something I did fixed the program and I really didn't get 
>to take the time to really figure out which change 
>corrected the problem.

It appears that my brief response has been misinterpreted.  I often post
long, dreary answers, and in trying to be concise, it appears I have been
terse instead.  Let me therefore expand on my brief sentence.

I do not intuitively understand all code that has ever been written.  But as
a professional, I work very hard to move in that direction.  When I come
across something I don't understand, rather than  poking production code to
see how it twitches, I read every reference I can find, search the archives
of various mailing lists and back issues of various periodicals.  I always
assume that someone else has solved my problem before me (rather, I think
the converse: no problem _I_ am going to encounter is new to the universe.)
I don't work on cutting edge stuff, so my problems tend to be somewhat
plain.  In fact, they tend to be my own fault (like taking an SQL example of
null maps instead of a trigger example.)

I've done my homework and am still confused.  Now what?  Instead of "try
this" and "try that", I set up a test bed and pound it with as many test
cases as my little brain can dream up.  Please read the top sentence again
in this context and I hope you'll see that my intent was to say that the
code stays in test until I completely understand it.  Only then does it move
live.  It has been my hard-won experience that if I do not "take the time to
really figure out what change corrected the problem", then I really haven't
finished the job yet, and the code is not ready to go.  All too often, code
"fixed" in this way breaks in production, and _nobody can really explain
why._

So I am not patting myself on the back at all; instead acknowledging my many
shortcomings, and adapting my work ethic so that I do not put questionable
code into production.

Regards,
  --buck