"Oh, hey, that's weird." One of Initrode Global Insurance's accountants spotted an error on a printout of the previous day's sales report during her daily review. She dug through her records and tried to isolate the small, but still troubling, discrepancy between the totals. After reading through several previous days' reports and asking around, she couldn't find anything that could've caused the error. She circled the incorrect number, wrote the correct total, and took it to her boss's office.

"Hey, that's weird," her boss said. After checking and rechecking, it was clear — this was a problem with the report generated by the big iron (an IBM mainframe). After making the rounds in accounting and then through IT, it was ultimately put on a low level programmer's desk for him to investigate.

It was the mid 1960s, so naturally all of Initrode's applications were built in COBOL. The archaic punchcard system was in the process of being phased out in favor of a newer magnetic tape reel technology. For two years the system had performed well, and aside from the usual kinks when the system was first rolled out, there hadn't been any issues like this in months.

The programmer did all he could to find the problem, but wasn't able to locate it. After five days, still no resolution, but at least the issue hadn't shown up again. Everyone reasoned that it was a fluke, maybe a card with a hanging chad or a one-time read error.

Sadly, a day or two later (exactly one week week after the issue had originally appeared), the same thing happened. Another negligible difference between accounting's paper reports and the computer's output.

The developer went to the card bin to verify that none of the cards were folded, spindled, or mutilated — nothing. He checked the numbering on the cards, and again, nothing. Another programmer was assigned to investigate, and between the two of them, they still couldn't figure it out. There was no apparent relationship to the job's parameters and the amount of the discrepancies. None of the equipment, code, or staff had changed, no accounting procedures were different, but this problem would still appear every week.

After a year, there was still no fix. Ashamed, the developer vowed to work late the next Thursday night, promising himself he wouldn't leave the office until it was fixed. He pored over every ENVIRONMENT DIVISION, every FILE SECTION, every WORKING-STORAGE SECTION. He checked every variable to make sure that the decimals were in the right place, that no precision was lost in any output anywhere, and that all data files were closed properly. At his wit's end and cursing the 1960s for not having invented Red Bull yet, he leaned back in his chair in frustration. At that moment, a member of the cleaning crew came walking through the door. She politely said "hi" and asked if her cleaning would disturb him. Happy to have another human being in the room, the young developer invited her in.

"No, it's fine, go right ahead," he said weakly. She thanked him and began her cleaning. The young developer got back to work and was pretty sure he was close to the bug when he heard a startling *crack*.

"Sorry," the cleaning lady said, picking up the hand broom she'd dropped. The developer's attention turned to her while she swept up some dirt into a small pile. Nonchalantly, she reached into the punch card bin and swept the dirt onto one of the cards, picked it up and carried it to the trash, and threw away the card with the dirt.

The developer may have wept then.

 

(thanks to Robert R. for the story)

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!