You can write the greatest program in the world that works 99.9 percent of the time, but woe unto you the first time it fails. Then get ready to play both detective and advocate if you want the problem fixed, as I learned on the job.
At our company, the payroll/HR department likes to maintain a hard copy of certain data. They have elaborate files for vacation time, health insurance information, personal time, and a general employee information card.
There are close to 20 divisions in the company, so HR asked if it was possible for me to write a program that would color code the top 1/4 inch of each card to identify which division it belonged to and make it easier for them to quickly file and keep track of the information. The requested data would be extracted from their HR program, which we purchased from an outside vendor.
Mission accomplished -- for now
I was able to quickly produce a program that would access the data, which was stored in an SQL database, and identify any new employees. As each card was printed, the program would match the correct color for their division.
The department employees were ecstatic, and the program ran smoothly for several years ... until one fateful day.
Someone from payroll called and said the wrong color was appearing on one card. The batch contained records for employees from several different divisions, and all the other cards in the batch were correct, but one employee's was not. HR was convinced that my homegrown program was causing the problem. I went in to find out.
I ventured over to the department to watch the program running, and sure enough, the cards for the one new employee printed with a top band of black when it needed to be purple. I investigated closer. Checking the code (about six pages single-spaced), it all appeared to be correct and unchanged.
Next, I looked into the raw data extracted for the new employees. In a few minutes, the problem came to light. Someone (no one admitted to it) had entered the wrong data for the card that was printing incorrectly. They had filled in the division field as ***N0 instead of ***NO. "NO" identifies a northern division, and of course ***N0 was simply wrong information.
Found, but not yet fixed
I pointed out the problem and the fact that their payroll program should not have permitted such an action. The commercially purchased program allowed an employee to select a company from a drop-down list, which is fine. But it also let the worker enter a new company identifier -- an ability that should've been left to an administrator, thus eliminating these kinds of issues. Instead, they were able to type in ***N0 instead of ***NO.
I notified the vendor of the problem but have yet to receive any thanks. I am not surprised.
Users must understand that the computer reads every character exactly as it is entered, not as we intended it to be. We also need to remember that programs have unexpected flaws, so we can never assume. Double-checking can save a lot of grief in the long run.