SELECTIVE IGNORANCE

Finding the Signal in the Noise

September 2007

My friends tell me that I'm good at making things break in surprising ways. Here's an example.

I recently ran out of disk space on my home computer, so I bought an external disk, the idea being to keep that disk connected to my computer all the time and use it for things such as pictures and audio files, both of which take up lots of space and are used only infrequently.

I connected this disk to one of the Firewire ports on my machine, because I want to use the USB port for low-latency purposes such as sending audio signals to an external sound card, and I fear that a lot of USB disk traffic might interfere. So far so good.

I have a second disk that I use for backups. Two of them, actually, with the same manufacturer, make, and model. To keep these disks straight, I'll call them the "backup disks" and the other one the "auxiliary disk." As I said, the same company made both backup disks, and it's a different company from the auxiliary disk.

Here's the weird part: When I connect one of the backup disks to the machine, the auxiliary disk immediately reports a permanent I/O error. Something about being unable to do a delayed write to the Master File Table, which sounds pretty serious. So the auxiliary disk must be broken, right? After all, it's the one reporting the error.

Not so fast! First, I can make the problem occur whenever I want: Just connect the backup disk to the machine and the auxiliary disk reports failure! If I don't connect the backup disk, the auxiliary disk hums along just fine.

But what is really weird is that if I connect the other auxiliary disk to the machine instead, there is no problem. In other words, I have two disks of the same make and model, one of them causes my auxiliary disk to report errors, and the other one doesn't. Which disk would you think is the real culprit now? Right, one of the backup disks.

So I went to the backup disk manufacturer's website to report the problem. I went through their registration procedure thence to their "report a problem" page, and finally I attached a screen shot showing the message.

When I submitted the trouble report, their website crashed.

After a decent interval, I decided to test the waters by submitting a trouble report about their trouble-reporting system. If that crashed, it would waste less time than sending in the whole original disk repoirt a second time. Fortunately, it went right through.

So I submitted the original trouble report again. Wouldn't you know it--their website crashed again! On the theory that what crashes it is trying to attach a screen shot, I tried one more time without the screenshot. Worked like a charm.

So now I don't know what to think. Is it so rare for a customer to report a problem and include a screen shot? Does the manufacturer just not care? Is something else dark and obscure happening that I don't know about?

No matter how you look at it, some bugs just shouldn't happen.

Posted by Andrew Koenig at 03:11 PM  Permalink |

My last post generated a few comments, one of which made a suggestion for what should be the second rule of debugging. I agree with that suggestion, and will elaborate on it later. But there is another rule that is even more important--so important that I see little alternative to calling it the zeroth rule.

Here's the rule: Before you go hunting for bugs, be sure that what you're seeing is a bug.

I've lost track of how many times someone has come to me complaining about what turns out to be correct behavior. The first example of such behavior that comes to mind is expecting (1.0/3)*3 to be equal to 1.0; but there are plenty of other such examples.

If a program's behavior doesn't match your expectations, it just might be your expectations that are incorrect.

Posted by Andrew Koenig at 01:41 PM  Permalink |