HomeSkepticismThe Lighter Side of Darkness

May, 2004
In my line of work as a software developer, I’ve come to realize that people in general would be under a lot less stress if they didn’t insist on clinging to two erroneous beliefs:

1. Some events have no logical explanation
2. All events can be traced to some conscious purpose or intent

Not true. Every event makes sense in some context, while some events—perhaps most events—are the result of random chance, not intent. Skeptics will recognize the above fallacies as some of the fuel that keeps the undying flame of cultural nonsense going. With the help of these distorted nuggets of wisdom, belief in UFO’s, ghosts, psychics, and other hocus-pocus continues despite all evidence to the contrary.

The need to believe is a well-documented human foible. Strangely, though, it is not simply the wondrous events that we want to believe in – it can also be the maddeningly irritating ones. For instance, when an office worker cannot find an important document, he may become angry. Very often, this anger blinds him to finding a solution to the problem. The paper couldn’t possibly be missing, because he has just set it down seconds before -- but it is missing. Someone, he decides, must have taken it. He then begins to imagine the elaborate conspiracy that would have to exist in order to steal this document from under his nose, without him being aware of anyone else in the room. Perhaps the receptionist had distracted him with a phone call, working in concert with an ex-Ninja from accounting, who crawled stealthily through an air duct… This kind of distorted thinking sustains and, more importantly, validates his anger. It is preferable for him to believe that his anger is caused by unseen, malevolent entities than that he is just upset because he forgot that he had already put the document in his briefcase.

Distorted thinking can be a great hindrance to problem-solving. I see this frequently in my profession, where something happens every so often that seems to defy logic itself. There is no explanation for it, so there is no way the problem can be solved. The problem is simply worked around, or the offending program/computer/system is discarded and never used again. Although no one posits aliens or ghosts in this type of situation, the lapses in critical thinking are similar to those of “true believers”. Decision-makers might blame the problem on monolithic entities like “Microsoft” or “Intel”, or perhaps some unknown “virus”, then wash their hands of it. Or, they may come to the irrational conclusion that the system “hates” them, is being “obstinate”, or otherwise assign human characteristics to it in an attempt to get a grip on the problem. There is a general feeling that, when something is unexplained, some sort of unseen intelligence is behind it, pushing levers and knobs behind the scenes, just to cause trouble. This is especially true when we are confronted with a frustrating problem whose solution evades us – we want to direct our frustration towards whoever (or whatever) is responsible. This mythical culprit is all the explanation required; most people (unfortunately) see no need to investigate further.

We humans tend to look for purpose and intent in the events we witness. Especially if an event has a strong emotional impact on us, we believe (erroneously) that there must be an equally strong intent behind it. It can be difficult to accept that most unexplained or unexpected events are simply random occurrences. However, in order to solve problems effectively, we have to learn to take a mechanistic viewpoint of the universe. That means rejecting metaphysical and/or supernatural explanations, focusing on cause-and-effect relationships instead of seeing events as blessings or curses, and adopting a willingness to carefully examine evidence that seems “mysterious” and “unexplained”, despite the fact that we desperately want it to remain that way. For many people, there is nothing more disappointing than finding out that some wondrous or mind-boggling event has turned out to be the result of perfectly ordinary circumstances. Therefore, if there is a logical explanation (and there always is), they don’t want to know about it.

Sometimes I wish I could toss reality aside as easily as so many others do, and wallow in the comfort of magical thinking. Unfortunately, the sort of thinking I have to do in order to be successful in my job won’t allow it.

To illustrate this point, let me tell the story of a mystery I once encountered. A few years ago, I was working for a company that supported a number of financial institutions around the country. They had access to our system 24 hours a day seven days a week, mostly through a web site. The system was made up of a number of custom-made server applications, some of which I had written, others that I simply maintained. At the time of the incident, I had been there almost two years and had worked most of the bugs out of the system. Consequently, technical issues that required my immediate attention became fewer and fewer. The system was set up to page me automatically if something was out of whack, but these pages were fairly rare.

On Christmas Eve, 2001, I had the day off and was about to go to a movie with my wife and her sister. Just before we were to leave, I began to receive phone calls from around the country that our web site was down. At the same time, I was receiving pages indicating that another part of the system was acting up. I told my wife to go on to the movie, and I would meet her there. Whatever the problem was, it couldn’t be too difficult to fix, since there had been no hint of a problem the last time I was there.

When I arrived at the office, I was met with an unexpected and decidedly unpleasant sight: The computers running the server applications were displaying hundreds of error messages. “ERROR CONVERTING DATE-TIME ENCODE”, they all said. I started trying to clear up the error messages, but whenever a transaction came through from a bank, another message appeared to take its place.

I stepped back to think about this for a moment. I knew from experience that when a reliable piece of software suddenly fails after having worked flawlessly for some time, then the fault lay in the data, not the software. The software hadn’t changed in six months, but the data were always changing from one transaction to the next. This time, however, the normal rule of thumb didn’t seem relevant. How could every single transaction, coming in with different formats and from different parts of the country, have the exact same flaw? It wasn’t possible.

So, the software wasn’t the problem. The data weren’t the problem. The hardware couldn’t be the problem either, because the same thing was happening simultaneously on a number of independent systems.

There was only one thing about the circumstances that was unusual: Today was Christmas Eve.

Could it be a virus? A digital “time bomb” set to go off on December 24, to deliberately ruin my holiday? That seemed the most likely cause at this point. A computer glitch doesn’t “know” a holiday from any other workday. There had to be someone behind it.

Resigning myself to the situation, I called my wife and told her to go to the movie without me. I then began to debug one of the programs that caused the problem, stepping line-by-line through the source code to see what was happening. After some time, I determined that the problem was with a routine that converted the date from the Microsoft format to the format that was used by the development environment. This routine was packaged into a reusable software component and included in virtually every program on our system.

In the world of software development, wishful thinking is deadly. Knowing this, I had tested this particular piece of code thoroughly when I had written it six months earlier. The question was: Why wasn’t it working today? I ran through it again and again, with the same result – “ERROR CONVERTING DATE-TIME ENCODE”. All the while I was saying, out loud, to no one in particular, “It hasn’t CHANGED! It’s the same as it’s ALWAYS been!” This was true – but it was also true that it wasn’t working.

For what seemed like hours, I banged my figurative head against the proverbial brick wall of logic, but it wouldn’t budge. Finally, in frustration, I engineered a “band-aid” fix by disabling the part of the program causing the problem. I had discarded the virus theory by this time and decided, finally, that there was a flaw in the Intel instruction set.

That night, I told my sister-in-law, who was also a programmer, how this previously unknown flaw had ruined by Christmas Eve.

“Really?” she asked. “Was it in the floating-point unit?” Intel had had this problem with the first Pentiums, years earlier.

“No, the ALU,” I replied, and even before I saw the look of incredulity on her face, it occurred to me that this theory was utterly fantastic. Without going into too much technical detail, allow me to explain that the Arithmetic and Logic Unit is one of the most basic components of a processor. Finding an unknown flaw in the ALU would be comparable to suddenly realizing that General Motors had been, for years, selling cars with no wheels.

When I got back from Christmas holidays, I took a less frantic approach to solving the problem of what had happened. What I found was that this was not the work of a hacker, of Microsoft, or of Intel. In fact, it was the work of…

Me. Myself. I.

The “Christmas Eve Virus”, as I had suspected, was not a virus at all. Nor was it a previously unknown flaw in the low-level computer architecture. It was a simple software bug. As intentional as it seemed to be, wreaking havoc as it did on Christmas Eve, it followed a logic of its own that had nothing to do with the fact that I had that day off and wanted to spend it with my family.

The bug didn’t know it was Christmas Eve. However, it did know that it was eight days before the end of the year. It also knew that eight is the number of leap days from that Christmas Eve going back to January 1, 1970, which was the reference date used to convert dates into digital values.

My routine converted the date format by first determining the year, then month, then day, assuming a 365 day year. It then went back and corrected for leap years.

All this worked fine until December 24 (actually, December 23, but no one noticed because it was a Sunday). On that day, the conversion routine figured out the year, month, and date before correcting for leap years and came up with January 1, 2002. It then subtracted the leap days and came up with January negative 8, 2002.

I defy anyone to find that date on a calendar.

This problem had seemed to flout all logic, and had looked for all the world like an intentional act designed to “get” me. But it wasn’t. On that Christmas Eve, I learned an important lesson: Everything, and I mean EVERYTHING, has a logical explanation. Nothing ever, ever, EVER defies logic. If it appears to defy logic, then I can be sure that I am making an invalid assumption. To put it another way, I am not putting the problem in its proper context. Invariably, it is I who has it wrong, not the Universe.

I also learned that not every random event has a purpose. Not every negative experience is the result of someone else’s scheme, or of Fate, or of a conspiracy. Some things just happen, and it’s either nobody’s fault, or it’s a mistake, or it’s an isolated incident. In most cases, there is no need to go any deeper than this. It’s best just to accept it and get on with your life.

So, if you see strange lights in the sky, or see a ghost, or get fooled by a simple parlor trick, at least consider the fact that there might be a perfectly ordinary explanation for what you see. Use a little of that gray matter you were born with before you run off and alert the tabloid press.