Debugging tools and oncall support

Debugging tools can require a fair amount of effort to set up, which sometimes earns them the reputation of being a waste of time. "Just put a DISPLAY message in the code, for God's sake!"says the project leader whose programming days are long behind him.

If a debugging tool is seen as a "waste of time" it is usually because the installation hasn't put enough effort into tailoring it for local use.

When we installed IBM Debug Tool in our shop, we altered all of our standard compile procs to support the TEST option and to link in the CEEUOPT module when needed. All the programmer has to do is select the TEST option on a panel and provide the VTAM LU of his debug terminal.

We never use the IBM supplied ISPF dialog to set up our debug sessions. I am not knocking IBM, but their dialog, of necessity, has to be generic, and like all generic tools requires a fair amount of effort to use. (This is where the "waste of time" perception comes into play).

We also provided each developer with a private DB2 data base for unit testing/debugging, and developed some in house tools to help them maintain them. This addresses data base contention concerns cause by people sitting at a breakpoint.

Finally, we renovated our once rarely used BTS environment to accommodate all of these changes.

It is the programmer who puts Display messages in the code that is "wasting time".

Masking test data

Many organizations demand that all identifying personal information be scrambled when a copy of production data is used for system testing. The idea is to limit the damage if the data is accidentally released to the outside world. Printing a test version of a client statement that accidentally gets routed to the mail room, for example.

As we found out a couple of years ago, masking can bite you in ways that you might not expect.

We were testing a new release of a recently developed system using data where the client's name was scrambled to a bunch of random characters. The testing went smoothly, and the new release went into production.

It was not until we were running in production that we realized that one of the screens was transposing the client's first name and surname on the data base. The error had gone unnoticed by the programmer and the testing / QA teams simply because the scrambled names lacked the visual cues that made the problem obvious once real names were used.

SDLC: system testing

You won't find these in any methodology textbook. Here are the 10 stages of system testing:

1. Unwarranted optimism: "Everything will be fine....it says so in the Plan"
2. Denial: "It must have worked...look at the results again"
3. Bewilderment: "What do you mean, it didn't work?"
4. Confusion: "That didn't work either!?"
5. Panic: "Nothing is working!!!"
6. Despair: "We're doomed...nothing will ever work"
7. Desperation: "Maybe if we call it an 'original bug' no one will blame us!"
8. Bargaining: "Maybe if we defer some more requirements to phase 2 we can get this phase finished"
9. Hope: "It's working now?"
10. Smugness: "I told you it would work. Just like we Planned it."
    

What stage is your project in?

SDLC: Production support

Ah, the forgotten phase of every project. Production Support never gets the respect that it deserves. It too goes though phases:

1. Disbelief: "But it worked during UAT!"
2. Denial: "It must be an implementation problem...not our fault"
3. Dodging: "Prod support can deal with it". And now the Prod support team takes a look at it...
4. Anger: "Those idiots on the project team couldn't have tested this"
5. Confusion: "What the hell is this anyway?"
6. Dismay: "Oh crap....there's no way that we can fix this"
7. Bargaining: "Wait a minute...isn't it still under Warranty?"
8. Glee: "It's screwed up, and it's not *our* fault!" Now it is sent back to the Project team....
9. Disgust: "Those idiots in Prod support couldn't find their butts with both hands"
10. ...there is no end to this list