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
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
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
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
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
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
continuously was 49.7 days. This was not
for a while, possibly because
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
and still have access to this
fossilizing operating system, the details of the offending device driver are as
Date Time Version Size File name
6/23/98 2:44pm 4.00.951 18,570 Vtdapi.vxd
The Musical "Bug"
is actually a feature rather than a bug. Microsoft started receiving the
support call about users complaining that their computer was
playing classical music! Heavy
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
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.
If you type the formula
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
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
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
, a small
of developers is responsible for testing the blenders, which the lucky fellows do by making margaritas. For a while, in a
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
burned out the drive
. So now the poor fellows are forced to test using real margaritas.
I don't know who invented this game, but several developer
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
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.