Dawning Dismay

I inquired what happened when there was trouble with the system. He answered that either the packers couldnt scan the bar-coded tickets into the cartons or the cartons would be packed incorrectly. That could cause customer shipment deadlines to be missed, trucks missing scheduled deliveries, and customer returns or charge-backs (credits). As I began to sense how high-visibility and high-risk a job this was, I inquired how big the charge-backs might be. As I recall, he said, As much as $50,000 per shipment.

For some reason, my hands started to get a little sweaty, so I asked who would train me in this job and perhaps temporarily share responsibility for support of this critical business function. My manager smiled and told me that I had come with this terrific reputation, and that I would have to tackle this one on my own.

Then I asked how often there were problems with the system, and he said, Quite often. By now, I had my handkerchief out and my eyes on the door, but then I thought about those nights in the motel and that I had left a job to take this one, and I determined to at least make it through the first day.

Probing a little further, I asked for the comprehensive application documentation for this critical RF business function, thinking that I could quickly get an overview of this apparently very comprehensive and heavily modified warehouse distribution software package. My manager smiled and told me that because of the very extensive in-house modifications made to the package of several millions of lines of source code, there really was no comprehensive application documentation. He suggested that I learn the system by reviewing the source code in the Radio Frequency bar-code scanning program, which controlled how the hundreds of warehouse packers scanned the bar-coded items into cartons based on customer orders for shipment.

I got myself a cup of coffee and settled into my quiet private office to (I hoped) quickly learn this new system by reviewing the big RF scanning program. Just how big that first program was became apparent when I utilized the computer source editor to review the program. This allowed me to look at seventeen lines of the source program at a time on my nice, large-screen PC. I scanned for the bottom of the source program and saw that there were some 7,600 source statements in the program, which meant that there were 447 pages of source code for me to review on the screen, and this did not include externally described files and copybook expanded statements.

So I decided to compile the source program and review the compile listing, which would include the externally described files and the expanded copybook statements. The compile listing was 300 pages long, and there were 11,500 source statements in the compile listing, including the expanded externally described and copybook expanded source statements.

I then wondered if this software package utilized program call statements to access other programs, which would perform part of the processing logic for this program. Some software packages break the application logic into many sub-programs, while other software packages put virtually all of the program logic into one pleasingly plump program. I scanned for the CALL operation, and was surprised to find 36 CALL statements to other programs from this program. That meant that I had to review 36 more programs to understand and support this one RF scanning program. I then reviewed the several dozen disk files that were input and output to the program, and found that, of course, I wasnt familiar with any of them.

To put this in perspective, one of the key programs that I had to support in my new company was about the size of this book, and it referenced 36 other programs during its program execution, and I had not worked on this vendors software package before. I had better get busy before something happened, and we couldnt pack and ship.

I had just gotten my second cup of coffee and flipped open the 300-page compile listing of the RF bar-code scanning program when my manager knocked on my door.

He was not smiling, and in fact he seemed a little excited. Something had happened, and hundreds of packers were not packing, and cartons were not flowing along the conveyors, and trucks would be arriving, and customer shipments could be missed, and there would be big charge-backs.

He asked if I, his new programmer with the stellar reputation, knew how to fix it, and I had to gently tell him I hadnt even known anything was wrongthe phone had rung in his office, and apparently in his managers office.

To his credit, my manager didnt ask me how long it would take to fix it, because by now he knew better than to ask that question. We both sat down to figure out logically what had caused the problem in this really incredibly complex real-time environment, in warehouses that were hundreds of miles away.

At that point, though I am generally opposed to guessing, I did use some of my trouble-shooting experience to root around and guess what might be wrong. Having no other possible solution, we tried my guess, and by gosh, it worked. Now I was the real expert, and I had narrowly escaped being well known (but not admired) by management of the company on my first day. I hate to guess about a critical programming problem, because that often leads to a series of wilder and wilder guesses, lost time and focus, and, ultimately, disaster. But in this one case I had no choice.