Working Up

by Dwayne Phillips

A change in the behavior of a system means that someone has changed something. We as people, often love to ignore this.

Here is a situation I experienced a few years ago in a digital signal processing laboratory. One day, a piece of software didn’t work. A user ran the software, and the software stalled in a state so that the process had to be killed by a system administrator.

Someone investigated the problem. They found that if they changed one line of code, the software would no longer stall. The error was corrected.

A skeptic, (those skeptics can be a pain, but we must have skeptics about to keep us honest) was upset with the “fix.”

“That line of code was the way it was for ten years,” chided the skeptic. “The software never stalled before.”

The skeptic was correct. The problem, whatever it was, was not in the software. Yet, changing the one line of code did fix the problem. The skeptic, however, was unable to convince anyone of his thought. Given some twenty years of consideration on my part, here is the convincing:

Something had changed to “break” the software. That errant line of code had been present for ten years and had never caused a problem. Now, all of a sudden, out of the blue (toss in any other cliches you know), that line of code was incorrect(?).

Some possibilities:

1. The data the user ran on the software caused something that had never occurred before.
2. The operating system of the computer had changed in a way so that the line of code damaged the operating system.
3. There were too many people running too many programs with too much data on the computer. That new situation caused the software to stall.

Given time, I could create other possibilities.

What did we do? We kept the change in the one line of code. After all, the software did run correctly after the change. We did not investigate any other change possibilities. After all, the we had too many other things to do that day. We never knew what really caused the software to “break.”

Still, I must go back to the italics statement earlier. The software worked one day and was broken the next day. Something changed, else the software’s behavior would not have changed. Practical considerations, e.g., time, money, headaches, etc., pushed us on to other things.