Joe woke up suddenly with the telephone nagging him shrilly. The illuminated face of the digital clock beside his bed showed 3:12 a.m. He grabbed the instrument to silence it. "Hello," he said groggily.
Joe woke up suddenly with the telephone nagging him shrilly. The illuminated face of the digital clock beside his bed showed 3:12 a.m. He grabbed the instrument to silence it. "Hello," he said groggily.
"Joe," said a familiar voice, "This is the computer center. Remember that system you put together for Bill about two years ago? It just blew itself right out of the water."
"That's impossible. There hasn't been a problem with that system in over a year."
"Well, there is now, and it couldn't have come at a worse time. Bill has a meeting tomorrow -- and he's invited everyone in the company -- where he's going to announce the company's one hundred thousandth customer."
That one hundred thousand number stuck in Joe's mind. He couldn't quite see what it might have to do with the problem, but it was such a round number! "Oh, well, probably just a coincidence," Joe thought as he struggled into some clothes.
At 4:00 A.M. the computer center was an island of light in a dark sea. Joe examined the program dump with some distaste. "I wish I'd put in some good error checking routines.", he thought glumly as he looked at the voluminous and semi-incomprehensible dump. "I know I planned to."
Joe dug into the dump listing and, as a grey dawn began seeping into the computer center windows, he made a very peculiar discovery. The program had blown up when it tried to create a new customer with a customer number of 00001! "What is going on here?", Joe thought. "The last time I checked the customer numbers were up at almost 70,000." Suddenly, Joe remembered what the computer center guy had said when he called, "One hundred thousandth customer!". It felt as though someone had just poured a pitcher of ice water down his spinal cord. The customer numbers had reached 99,999 and rolled over like the odometer on a '57 Chevy to... Yes, there was a new customer on file with a customer number of 00000 that had already made some purchases. Joe would have to build a new database with a six-digit customer number, copy the old database into it, manually change customer 00000 into customer 100000, and...
Calling Bill, the unit manager, at 6:00 A.M. wasn't fun. "The system can't be down today," said Bill shrilly, "I've got half the front office coming in for a meeting about the one hundred thousandth customer."
"Er, well, as a matter of fact," Joe stammered, "that does seem to be related to the trouble were having. There may be some difficulties with account 00001 as well."
"00001! That's the Chairman of the Board! We gave him that account specially as an honor when we brought up the new system."
Fortunately, it was Friday. Joe set a company record by working 48 hours in a three-day period and did manage to get the system back up by Monday morning. Bill had shown up at the computer center at 6:00 a.m. on Monday morning and loomed over Joe for two hours like a gargoyle on a cathedral roof, periodically saying, "How's it going?" A rumor went around the office that a packed suitcase was spotted in the corner of Bill's office on that Monday, and there was a plane ticket to Argentina in his coat pocket. He denied it.
Joe should be ashamed of himself for thinking that the system crash and the one hundred thousandth account was a coincidence. As Goldfinger once said to James Bond, concerning the latter's constant interference with his plans, "Once is happenstance, twice is coincidence, three times is enemy action." In data processing we should never reach the enemy action stage, forget twice, there are no coincidences, and there's not much that even fits into the happenstance category. If two unusual events occur at the same time, they ARE related, even if you can't immediately see how.
Did you notice that there are a few time bombs still waiting to go off in this system? The transaction counter will roll over at 65,536 with results that are dire but hard to predict. That could be a worse situation than the account number problem; there the program failed at an early stage when it tried to write a new database record that was already there, but when the transaction number rolls over to zero, the programs could continue their incorrect processing for quite a while before something occurs that's serious enough to blow the program out of the water.
Remember the two little data files from the mainframe that crept into the system by the side door and became manual data entry steps? Here's what happened to them. As the system volume went up, the little data files from the mainframe grew along with them. They became adolescent data files when they hit 300 items a day, surly, hulking teenager data files at 500 a day, and sumo wrestler data files at 800 items a day. Since the data all had to be entered prior to start of business each day, Bill had to hire four additional data entry operators to come in at 6:00 a.m. to help with data entry on his new, highly automated system. This happened over a period of several years so the increase wasn't immediately obvious to Bill. When he finally noticed he had one of the larger data entry areas in the company, he commissioned a new project to automatically upload and post the data every morning.
So, in the end, the new system will require more people to run it than it might have needed, and it will periodically have a massive blowup. The combination of the documentation being incomplete and incorrect, and Joe's programs -- although technically fine -- being totally incomprehensible, will make the system almost impossible to enhance once Joe move on to another area.
Still, the system does work and the customers and users are happy with it. The blowups occur at wide enough intervals that everyone has (almost) forgotten the previous one by the time the next one occurs, and, in any case, they all assume that the problem must be of recent origin -- not something that goes all the way back to the original coding.