...either by finding a clever way to use someone else's bug, OR by finding a way to use your own bug to implement functionality in a new way.

So, I ask you, when has a bug become a feature?

For voting purposes, please limit yourself to one example per answer.

I'm hoping answers will inspire people to rethink their implementations. Please take advantage of community wiki tagging if you think you can rewrite this to be a better question.


Mattel did in the 1980s:

While testing the game, Bill came across a bug: every now and then, the game would, seemingly at random, hyperspace you. He and his boss, Mike Minkoff, went over the code with a fine-tooth comb before realizing what the problem was: the Intellivision hand controllers encode button presses in such a way that an action (side) key pressed at the same time as particular directions on the disc will be interpreted instead as a numeric key being pressed. There was no software way around this; shooting while moving would occasionally be interpreted as pressing 9 -- the hyperspace button.

After several days of puzzling over a solution, the bug was ultimately "fixed" by including the following note in the instruction manual:

"Every once in a while, your space hunter will move near a 'black hole,' and the computer will automatically put him into HYPERSPACE. This will cost you the same number of points as if you had pressed the HYPERSPACE key yourself. On the other hand, it will save your hunter."

This led to an axiom frequently heard around Mattel: If you document it, it's not a bug -- it's a feature.


As a kid, I wrote a game in BASIC for the Commodore 64. I was by no means a good programmer, and didn't realize that GOSUB should always be paired with a RETURN. Needless to say, eventually you would get a stack overflow. I had no idea what that meant at the time, so I just trapped that error and told the player that they had survived the dungeon long enough to win the game.


It wasn't me, but somebody had to post it...

alt text

From http://crossthebreeze.com/2007/08/31/its-not-a-bug/ and probably 1000 other places on the web.


Rounding errors in one of my Paint.NET plugins caused an entirely different effect to be produced with certain angle settings. I split this into a separate plugin.


Windows Vista Aqua


I already posted about it. A bug I introduced once allowed me to recognize the stolen code because a similar service popped out after mine, and had exactly the same bug.

But I want to remember the Elite II - Frontier wormhole bug. That was defintely a bug became feature.


On many occasions I have used buggy plugins or music apps as a source of unexpected sound once on an early project I even settled for the buggy version after making the "correct" one, because I liked the bugs more than what I thought I wanted.

Misbehaviors and broken algorithms are exploited in music, constantly, to the extent that you could almost say that the only truly buggy plugin is one that crashes its host. Look at how people misuse autotune in order to accentuate its artifacts, how many techno artists exploit skipping/glitching, many people also use the sounds of pitch shift artifacts ... the list is very long, and stretches back into the analog world too - early electric guitarists before the distortion pedal was invented would provide the "wrong" power levels or damage components in order to distort their guitar's sound.


This one isn't mine either, and it isn't computer related. Interesting nonetheless. It comes from the book The Design of Everyday Things.

After word got out that I was collecting instances of design peculiarities, a friend reported the following about the sunroof of his new car, an Audi. Supposedly, if the ignition is not on, the sunroof cannot be operated. However, a mechanic explained that you could close the sunroof even without the ignition key if you turned on the headlights and then (1) pulled back on the turn-signal stalk (which normally switches the headlights to high beam), and (2) pushed the close control for the sunroof.

My friend said that it was thoughtful of Audi to provide this override of the ignition key in case the sunroof was open when it started raining. You could close it even if you didn't have your key. But we both wondered why the sequence was so peculiar.

Ever skeptical, I asked to see the manual for the car. The manual was explicit: "You cannot work the sunroof if the ignition is off." A similar statement appeared in the discussion of the electrically powered windows. My friend's mental model was functional: it explained why you would want such a feature, but not how it worked. If the feature was so desirable, why was it not mentioned in the manual?

We searched for another explanation. Perhaps it wasn't a design feature, after all. Perhaps it was an accident of design. Perhaps turning on the lights and pulling back on the stalk connected the electrical power to the car, overriding the fact that the ignition key was off. This would allow the sunroof to work, but only as a by-product of the way the lights were wired.


The various CSS parsing bugs in different browsers have been used in many a CSS hack as a browser-differentiating feature. There're certainly better, JS-driven approaches for this, but this case fits the question like a glove.


I suppose this story fits the bill:

I've heard of several rumours among the financial community where a trader's spreadsheet had a bug in it.

Upon being fixed by the IT dept the trader got all huffy, because the bug had given him a 'random' edge, causing him to win more contracts than his competitors, purely because he reacted according to incorrect data!

In short, the IT dept created a bug in already working software. Note that because the trader was the one making the money, his bug was put back in place. Other traders used the newer (and actually fixed) spreadsheet and didn't make as much money.

This is probably urban legend stuff tho.



Unintended behavior has as much utility as a screen door on a submarine. Bugs are like the One Ring, they cannot be used for good.