Sure, it wasn't a showstopper, and not many reservations were generally booked during that hour -- at least, not in that era. With the growth of the Internet since then and anytime-anywhere Web access, it could very well have blown up into a major issue. In any case, we were able to find it and fix it simply because we happened to be looking for problems at midnight.
Look for one problem, find another
Now working at a manufacturing company, I stumbled into a similar scenario more recently. We have a system controlling a production line in the mill that has been in place for about two years. It was provided by a vendor and includes a website for reporting on the products that have been run through the line.
One day, I was chatting with another employee. As we were about to go our separate ways, he mentioned something about the format of the website. He said it was annoying to have to use a scroll bar to go back and forth to see the columns in a table. He suggested rearranging the table to push the less important information to the right, so that the most important information was easily viewed without scrolling. This table is seen by several employees every day to keep track of production and run reports. It has one row of information for each product that comes down the line during an entire shift.
Another programmer and I took a look at the code to see what could be done. In the process of analyzing the columns of data included in this table, we discovered there were two columns for the weight of the product: entry weight and exit weight. The entry weight was sensible, since it was provided to the system as a characteristic of the incoming product. But there should not have been an exit weight at all -- there wasn't even a scale in the line to weigh the product. Plus, the weight did not change during the process that the data in this table was following.
But there it was: The data clearly showed that each piece in the line weighed about 3 percent less when it exited the line -- a phantom number. Not only was this information unnecessary, it was also wrong. In two years, no one had ever mentioned this discrepancy and had instead ignored it.
We fixed the original scrolling issue and took out the exit weight from the table. We still don't know how the system came up with the new weight. But who knows how much longer it would have remained in the table if we hadn't been fixing an unrelated issue?
I'm still amazed at how often I stumble across programming logic that is not logical or found bugs that might not otherwise have been mentioned. I guess the constant discoveries lurking on the next line of code keeps the job from getting dull.
Send your own IT tale of managing IT, personal bloopers, supporting users, or dealing with bureaucratic nonsense to email@example.com. If we publish it, we'll send you a $50 American Express gift cheque.
This story, "Looking for bugs in all the wrong places," was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.