Developers are prone to blaming their bugs on freak occurrences or unusual conditions. Anything that can direct the blame away from their code is fair game for a developer frantic to explain away a
tenacious
bug. The cry goes up: "I can't reproduce the bug, so it must have been a full moon/cosmic rays/in an older version/already fixed/a problem between the keyboard and
chair
."
One such bug struck two MIT researchers who were writing some code that generated comments into a file of LISP forms. Normally the code worked fine, but at regular times in each month the resulting LISP forms would fail to compile. The
Twilight Zone
feeling arrived when it became clear that the program only failed during certain phases of the moon!
The cause of the bug was that the comments being written included the phase of the moon as part of their text. This
meant
that the comment lines were of variable length. At certain times of the month, the comment line length would exceed the page width of the LISP form. This automatically ran the comment onto a new line, which was then no longer perceived as a comment but as executable code, thus
causing
the compilation failure.
The 49.7 Bug
This bug was originally thought to be mythical, but it is now recognized as a real bug in a device driver that is part of Microsoft Windows 95. The rumor was that the maximum number of days that Windows 95 could
operate
continuously was 49.7 days. This was not
verified
for a while, possibly because
uptimes
of longer than a month are rare in the wild. However, this has now been confirmed as a timing problem in an obscure device driver.
For those of you who are
curious
and still have access to this
rapidly
fossilizing operating system, the details of the offending device driver are as
follows
:
Date Time Version Size File name
----------------------------------------------------------
6/23/98 2:44pm 4.00.951 18,570 Vtdapi.vxd
The Musical "Bug"
This
next
curiosity
is actually a feature rather than a bug. Microsoft started receiving the
occasional
support call about users complaining that their computer was
randomly
playing classical music! Heavy
medication
was the obvious diagnosis, or perhaps even a virus, but this "bug" turns out to have an interesting origin.
From 1997 onward, the Award/Unicore company produced several PC BIOSs and motherboards containing an electronic
hardware-monitoring
component. This component was designed to detect whether the CPU fan was failing or had failed, and whether power supply voltages had drifted out of tolerance. If the component spotted any such problem, it signified the discovery by playing either "Fur Elise" or "It's a Small, Small World."
If you're having a hard time believing this, take a look at the Microsoft Knowledge Base article number Q261186.
Deliberate
Excel Bug
If you type the formula
=DATE(1900,2,29)
into any version of Excel, this date will be accepted even though it's actually invalid ”1900 is definitely not a leap year. In case you're interested, the rule is that all years divisible by 4 are leap years, except those years divisible by 100; the exception is that all years divisible by 400 are leap years.
The reason for this Excel bug appears to be a deliberate compatibility decision by the Excel team. Back when Lotus 1-2-3 was by far the most popular spreadsheet application available, the Lotus developers
accidentally
created this leap year bug. In order to maintain compatibility with the Lotus spreadsheet application and to be able to use the same date serial number scheme, the Excel developers decided to copy the same bug. In fact, all days of the week prior to 1 March 1900 are
reported
by Excel as one day earlier than they actually are. Microsoft claims that fixing this bug would create many more problems, presumably in existing spreadsheets.
The Margarita Bug
At an appliance company that builds
blenders
, a small
group
of developers is responsible for testing the blenders, which the lucky fellows do by making margaritas. For a while, in a
politically
correct environment, they only used virgin margaritas (those made without any alcohol). This changed rapidly after the first of a new series of blenders all failed. Apparently, the alcohol depresses the freezing point of the mix, which loaded the electric motor more heavily, which in
turn
burned out the drive
transistors
. So now the poor fellows are forced to test using real margaritas.
The
Lunch
Game
I don't know who invented this game, but several developer
shops
now play it. The idea behind the game is rather simple. Whenever somebody creates a new procedure, that person has to add a random day of the week in the header comments of the procedure.
After the procedure has been deployed into production and a bug has been found in it, the person finding the bug looks at the day of the week in the header. If somebody other than him- or herself wrote the offending procedure, and the day in the header is the current day, the person who wrote the procedure has to buy lunch for the developer who fixes the bug.
This has two interesting results. First, it encourages
extensive
testing for bugs, and second, it encourages you to fix any bugs that you find as soon as possible. This is because if the bug is in a procedure that you wrote, fixing it means that you avoid having to buy lunch for somebody else. If the bug is in somebody else's code, fixing it means that somebody buys lunch for you.