What is the Best Bug-as-a-Feature?

Bat Country wonders: "The workflow system, at the department I develop for, was hand-coded by my predecessor in a rather short amount of time, resulting in somewhat unreadable code with a number of interesting 'features.' When I took over maintenance of the code base, I started patching bugs and cleaning up the code in preparation for a new set of features. After I was done, I got a pile of complaints about features that had disappeared, which turned out to be caused by the bugs in the code. So, that leads me to ask: what is your favorite bug that you either can't live without or makes your life easier?"

Re:The best

[Anonymous Coward]

Apparently your "bugs" were the features and your "cleaning it up" broke a bunch of shit. Congratulations and good luck finding a new job!

buffer overflow

[virtualXTC]

buffer overflows are great - they allow you to get root on all sorts of devices that some bastard tried to lock you out of.

QW strafejumping

[dybvandal]

Easily the best bug ever. Its been paramount in enabling continous "innovation" as people speed jump through maps.

ModeX graphics? Buffer overflows?

[Kufat]

The famous undocmented 320x240 VGA video mode, pre-VESA, and other tweaked VGA modes.

I've heard the 6502 (or, more specifically, RP2A03) had some useful undocumented opcodes. I think they weren't intentional, so they might count.

On the software side...how about exploitable buffer overflows on the Xbox and PSP to enable execution of arbitrary code?

That's simple...

[sherpajohn]

The bug in evolution which allowed Homo Sapiens to gain language and self awareness. Gaia knows it never should have happened! But I am sure it will corected shortly (that being shortly in the cosmic scale of time).

Re:Personally, I like... Actually...

[Volante3192]

Minor quibble, PC means Paper Cartridge in that context, not user.

WarCraft II Bloodlust

[moore.dustin]

While it made the game, more or less, a one race game, it added a huge element to the end game, which is where War2 multiplayer shined for some time. It brought the need to micromanage to the board, which, while always a factor, was not essential to victory.

So in essence, it brought heavy macromanagement and micromanagement together.

Re:Yes

[pilgrim23]

though Windows does this with flying (Blue) colors, I would nominate DRM. it screwed music and spurred development of P2P

Re:Perl versus Python

[zippthorne]

As an engineer, I'm also amused.

4.0 is definitely a 2 sig dig number, but 4 could be 1 sig dig or it could be "exact." You wouldn't say the 2 in 2*pi*r is only one significant digit, would you? Of course not, it would render any precision in pi or r meaningless.

Also, 1200 could have 2, 4, or be exact depending on the context. It's best to always use a notation that includes the fraction mark for non-exact quantities.

Re:Skiing in Starsiege: Tribes

[Rimbo]

Rocket-jumping in Quake, for that matter. Totally unintentional, but became a key part of the game.

Re:Perl versus Python

[xero314]

4*1200 yields 5000

If that isn't a bug, I don't know what is.

That is because the IEEE standards for floating point values is the biggest and most prolific bug in software today.

Re:Perl versus Python

[Anonymous Coward]

I personally choose the symbol 4 to represent the value that is one greater than the value represented by the symbol 6. I further choose composite symbol 4.0 to represent the value that is one greater than the value represented by the symbol 9. I assert that the values represented by symbols 6 and 9 are not equal in their position on a number line.

Therefore: 4.0 is definitely not equal to 4.

It's all in the interpretation of the representation.

Re:Perl versus Python

[Anonymous Coward]

If you assume 4 is an integer and 4.0 is a real number, then 4 and 4.0 are mathematically equal.

If you assume 4 is an exact number and 4.0 is an inexact number, then 4 and 4.0 are mathematically inequal.

The problem has nothing to do with integers and real numbers, or the internal binary representation of integers and floats. The problem is that there is no universally accepted map from the ascii representation "4.0" to an object.

Re:Perl versus Python

[Anonymous Coward]

Why would a mathematician expect them to be equal?

Because real numbers, floating point numbers, inexact numbers, and scientific precision numbers are four different sets. And which set you think "4.0" belongs to depends on whether you're a mathematician, computer scientist, engineer, or physicist.

Lesson here is:

[geekoid]

Don't start modifing code until you understrand how the users use the product.

It is only refactoring if the users sees no change, with the sole exception of performance gains.

Re:The Easy to Interpret Save Files in X-COM

[bigdavex]

Why not just delete the whole directory and put this?

echo You win!

Intestinal flora

[tverbeek]

The bacteria in my digestive tract are bugs I would definitely miss.

Re:Perl versus Python

[Chirs]

Not in programming, but in engineering.

Quite often calculations are performed where the various values are known to have a certain amount of uncertainty. If I take a reading of "4", what is really meant is that the value is between 3 and 5. If I specify "4.0", then the value is between 3.9 and 4.1. The amount of precision is given by the number of significant figures. Thus, a value of 4.0000 implies a fairly high degree of certainty.

Given that "4" has only a single significant figure, multiplying it by an exact 1200 yields 4800. However, if you round that off to a single significant figure, then the result is 5000.

As has been discussed already, however, the "4" may be exact, in which case you need to know the uncertainty in the "1200" before the uncertainty in the result of the calculation can be determined.

Re:Perl versus Python

[UserGoogol]

Those filthy engineer types think that numbers are merely an approximation of reality, and thus to them precision is relevant. Whereas mathematicians don't give a shit about reality and just want to work with the numbers, and a number describes itself perfectly. And when they're forced to go into the land of finite precision for whatever reason, they generally don't feel compelled to sully their numbers with that junk, so they represent precision in different ways.

Ah, Units

[EgoWumpus]

As a programmer, and a former student in at least one other math-related discipline, it's clear to me that 4 and 4.0 are equal. But they are not equivalent. Knowing 'Accuracy', 'Precision' and 'Proper Use Of Units' like the back of your hand will help you in any career.

Re:rm

[cswiger]

Nice. Perhaps having rm look at a filename called "-i" and interpret that as a command-line flag is probably the best "bug as feature" offered so far. :-)

Re:Perl versus Python

[porpnorber]

As a mathematician (or at least, an ex-mathematician) I am always amazed by mathematicians who forget that 'equality' between distinct domains is introduced (in standard developments) as a mere abuse of notation. Just because there is a canonical injection of Z into (say) Q does not mean that any element of Z is equal to any element of Q in any normal sense.

Moreover, since 4.0 is a floating point number, it's not even a very helpful abuse of notation to allow 4 and 4.0 to be 'mathematically' equal, since you can demonstrate that mathematically all floats are equal to each other: there's some nonzero epsilon small enough that epsilon + x is 'equal' to x. It is not helpful to then apply normal mathematical reasoning and conclude that all integers are equal - that is, it's nice to maintain some part of a programming language that is actually consistent, and if we're going to use the symbol '=' for both types, it's helpful at least to maintain that these are distinct overloads!

Really, any programming language for the mathematically savvy would issue a warning whenever you used a floating point type for anything; floating point support is a somewhat lame compromise for hardware compatibility. If on the other hand we had the habit of using constructive real numbers (which, unlike classical real numbers, are implementable), we would, quite rightly, be forced to reconsider the notion of equality globally.

Re:404

[LarsG]

That message is produced by the IBM BIOS, and not MS-DOS. While I love to point fingers at BillG, IBM is to blame for this one.

Re:The best

[Gyppo]

Interesting that you're fixing a workflow system but you don't seem to have any of your own. What a developer considers bugs may not be considered bugs by the end users - and even if they are considered bugs, end users usually have work-arounds for them. If the bugs disappear, you've broken their work process. You may want to investigate collecting requirements and getting user buy-in before deciding to change their system. I've worked on systems where I've done something that I consider insignificant like changing the navigation, but the users didn't know that it was changing and started logging bugs, assuming something was broken.

Re:The best

[RollingThunder]

Yes and no...

what if one of the bugs was that authentication wasn't checked when it should be? Users hate entering passwords, and fixing that bug would REALLY annoy them.

Some UAT would have helped on that, though. The OP wasn't clear if the complaints happened after release, or during pre-release user acceptance testing.

Did you clean up the code or break the code?

[WindowsTroll]

Your assumption seems interesting to me. In a production environment end users are using an application that obviously is useful. In your attempt to "clean up unreadable code", it no longer works. What you did instead was make the code perhaps more readable, but you changed the functionality. Perhaps more pejoratively, you broke what was previously working. Instead of looking at your self to see what you broke, your assumption is that it all worked by accident.

Before committing any changes to a production system, I would expect that a developer would test the functionality before making change and compare the results after changes were made. This would have uncovered that you changed functionality. Another tact would have been to create unit tests before making your changes, and then run those test as you were making changes. You have have discovered that you changed functionality. Instead, you did neither, and you broke a feature.

I'm a little long in the tooth, working 18 years as a programmer. I've seen this situation many times. Every young new hire thinks that they are smarter than the people hired before them and that all of the existing code is crap. It all needs to be rewritten because the previous coders were bad programmers and if it were redone, it would be cleaner. So they rewrite existing code and they break things. I can only assume that you work for a PHB.

Any manager worth their salt would initially halt a rewrite of WORKING code. If you want to modify something that is working and has been working and has had the bugs worked out, you will really need to prove that there are benefits to doing so. And as a manager of a development group, anytime someone who is still wet behind the ears wants to rewrite code, I tell them to step back and look at the code again. Is the code really crap or is it that you just don't understand what it is doing? Perhaps having an older coder walk through some of the code, maybe explain why the code was written a certain way, might shed some light on how it is really functioning. The fact that in your case you changed functionality, it shows that you didn't understand what was going on in the first place.

Re:Did you clean up the code or break the code?

[FooAtWFU]

In an Ideal programming environment, you will have a maaaaassive collection of unit tests, such that you can tell if your cleaning-up-the-code actually broke the code you cleaned, or not. And if that's the case, the real question is whether the time spent cleaning would be better fixed elsewhere. Often it might be. Sometimes it's worthwhile, though. If nothing else, it can be good for morale. (It feels good to turn a 50-line abomination into a neat little 4-liner.)

Re:Perl versus Python

[Coryoth]

As a mathematician (or at least, an ex-mathematician) I am always amazed by mathematicians who forget that 'equality' between distinct domains is introduced (in standard developments) as a mere abuse of notation. Just because there is a canonical injection of Z into (say) Q does not mean that any element of Z is equal to any element of Q in any normal sense.

Kudos! Someone who actually understands mathematics. There exists natural injective maps from N -> Z -> Q-> R -> C, but they are actually different domains, and not strictly, subsets (as people like to presume for convenience). To see this clearly (and simply), consider the formal defintions for a natural number 4, and the rational number 4, in set theoretic foundations: the first is finite set, the second is an infinite equivalence class. Clearly they are different objects.

Re:Perl versus Python

[zsau]

Funny. Back in the day,[*] the story was version 4.0 of a Microsoft product was to be avoided. Think, in particular, MS-DOS.

[*]: I was too young back in the day to know this first hand.

Re:Perl versus Python

[slawekk]

As a former mathematician I am always surprised by mathematicians who think that the natural number 4 (that is the set {0,{0},{0,{0}},{0,{0},{0,{0}}}} ) should be equal to any real number (which are usually some sets of Cauchy sequences or Dedekind sections of rational numbers).

Re:Perl versus Python

[Gooba42]

Ugh, precision vs. accuracy again...

I had a geometry teacher in high school who asked for the most precise possible answer...

When I gave her 3*pi, she told me that was wrong, I should have given her 9.42 and my arguments that 3*pi was precise to infinite digits while 9.42 was only an approximation fell on deaf ears.

Just another instance where the correct answer and the right answer are different.

Re:Ever want to sort an inhomgenous collection?

[goombah99]

Boy I shudder at how wrong that is. You mean to say that you never encounter collections of inhomogeneous objects? Ever used a database? I'll give you two examples:

I probably do use such a list, but only rarely; I can't think of the last time I have (well, apart from writing Lisp code, where the code itself is such a list). And yes, my job is writing and using an object-oriented database with Python. Is what I do. Where you get nonhomogeneous objects is in the values of the {key:value} dict of attributes attached to each object in the database, not the database object keys (which would be silly).

No it's not silly. it's not at all uncommon to want to sort a list on values. Moreover, sometimes the point is to reconcile lists of things gathered from multiple databases or tables that do have different key types. I guess we work in different arenas. I assume in your work you are used to dealing with your own curated data bases. In the Bioscience arena one is always interacting with multiple databases from all of the world trying to gather records in whatever form they come in and reconcile differences and similarities in the storage formats for the same entity.

So you sort the list of keys. The type of sort does not matter just as long as it always produces the same rank order for the same collection.

I suppose if I ever needed to do this, I'd take the extra 0.1 second to type ", key=id". They're guaranteed to be unique, unlike the result of a stable sort (which you seem to call "unstable").

This would fail. the ID of two identical instances of an object are not identical. It's not guaranteed in python that two identical immutables will _always_ share the same ID. (python tries to do so when it can). Moreover in computer science one generally wants comparisons to be fast because comparing a million objects against a million objects always takes more than "0.1" seconds. That dimissall is uncalled for.

Or you could sort the two lists in some stable way.

You keep using that word. I do not think it means what you think it means. I'm afraid I do. But I'll give you that the word is being tossed about colloquially here, though I think its meaning is clear in context.

One could go on all day.

All these examples presuppose you have an object database which has as a primary key a value which is sometimes a Unicode string, sometimes a number, sometimes an octet array ... WTF kind of database is this?

Not all data base keys need to be typed homogenously. That's rather narrow thinking. The only primary attribute of a database key is that it be immutable or at least hashable to an immutable. If you want to go on and require that the type must also be homogenous then that's a higher order definition. And not one that occurs universally in the real world. It can only occur in well curated monolithic databases where it can be enforced. Moreover, it's not always the keys one is sorting, sometimes it's the values.