An instance of - "It is a feature not a bug"?

Question

Well, I cannot recall any instance of this quote "It is a feature not a bug". I want to know about any incident where a bug has been presented as feature. Can anyone enlighten me about this?

Answer 1

This is perhaps more relevant for games, where a bug in the logic has had interesting gameplay side affects. There is a post over at gamedev.stackechange.com with a story of a bug that became a feature.

Another area I could think of is experimental visualizers. You could perhaps screw up the math for something and produce a wildly different result, perhaps even better than what you were trying to achieve.

Answer 2

Jeff Atwood talks about incorrect font when building Windows applications in Visual Studio. Perhaps this is one of the many real world incidents which lasted many(>4) years.

It also reminds me of:

Answer 3

The real meaning of "It's not a bug it's feature" is probably "It's not a bug it's a Feature Request". See link to blog of Jeff Atwood in other answer. This case is really very very common, I believe it could applies to most "bug" ticket of my application tracking system.

Now does it also occur that actual bugs become features ?

It probably happened ten times or more on projects I worked on in my career (about 25 years). I have a very simple example in mind that is probably the most extreme case.

I was working on a network application (pre web) where users had to type a login and a password. In early testing stages there was a huge (overlooked) bug. When login or password was empty the process segfaulted and was immediately cutting the connexion. This was discovered when showing beta to a user. Project manager explained shamelessly "Yes, this is the normal behavior when no password is typed, as no password is forbidden". The bug was corrected but the feature kept.

I'm thinking of this old password bug, because last month I stumbled upon a very similar bug using MS Active Directory. As far as I understand LDAP you can connect to an LDAP server just to check the identity of a user. If a user or it's password is incorrect LDAP returns an error (and the python LDAP layer I'm using raise an Exception). But with active directory the behavior is different when the password provided is empty. The login is always considered as valid (no exception, no error). When I connect to openldap with the same credentials the behavior is the one I expect : an exception is raised. Looks like a bug in MS AD, but I imagine it could be argued this is a feature.

Other cases I remember were more of the gray zone : behaviors unspecified (or poorly specified) and what was implemented was really different from what the analyst had in mind (but WTF, if he had something else in mind it should have written it down better). Sometimes code was changed, but it's quite common that the actual implementation is kept.

I also have an LDAP exemple for this one. In OpenLDAP if you use a schema to validate LDAP structure, the Schema validation is case unsensitive. But when accessing to actual LDAP content you must provide the correct capitalization of the keys or they won't be found. It seams clear enough that two parts of OpenLDAP code are using different specifications. Now I can't easily make my mind on which side has a bug and which side a feature.

Answer 4

There was a bug in the game Extreme G, which was left unchanged in the sequel.