Programmer Proximity Detector

Feature, apparently spontaneously evolving in programs, that allows the program to act differently in the presence of its author.

Typically this involves a user who claims that the program has a bug, but after calling the programmer over to the test facility (usually across the compound, requiring exiting the building and crossing a windswept parking lot in the rain, or taking an elevator 26 stories down to the subbasement), the bug does not manifest - the program works perfectly.

The user often serves as the proximity detector. Because the user is carefully showing the programmer how he (is supposed to) use the program, the user may use the program more slowly (thus hiding RaceCondition bugs) or exactly the way the programmer told him to use the program (thus hiding bugs due to slightly different inputs or orders of operations).

Isn't this page redundant with LawOfDemos?

(A HeisenBug!)

Precisely, but a specific type - only the presence of the author makes it vanish.

Seemingly a HeisenBug, but not really. This is a joke; let's not confuse people about the real meaning of HeisenBug.

Is it just me, or do inkjet printers show this behavior exceedingly often?

All printers do - typically converting into shredders on the author's printout.

Sounds like a special case of the LawOfDemos, where a flawlessly running program fails in a weird and never before encountered way in a thoroughly tested simple routine demonstration. According to murphy and the FallingHammerRule?, the probability of failure is naturally proportional to the importance of the event.

We have some brands of computers that recognize certain USB devices when plugged in the front but not the back. Some have their own power supply, so it shouldn't be a power issue. And it's not just one machine.

I've seen that with many USB devices on many systems; it looks to me like either 1) all USB ports are not created equal or 2) Some USB drivers are poorly designed and somehow bind the device to a particular port.

I lean toward the latter, because I've found that often (on Windows systems anyway) deleting the device from the Device Manager and/or uninstalling the device software and/or scrubbing the registry of related entries seems to "reset" the ports and allow a different USB port to detect the device.

This is unfortunately quite common in certain aftermarkets; for instance, just try to find a standalone video encoder that knows it's been plugged into the same machine, just a different port. Windows enumerates the encoder as the exact same device with a different DirectX ID. Tons of phun then you are trying to do a production configuration for release.