Slashdot Mirror
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?"
buffer overflows are great - they allow you to get root on all sorts of devices that some bastard tried to lock you out of.
Easily the best bug ever. Its been paramount in enabling continous "innovation" as people speed jump through maps.
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?
though Windows does this with flying (Blue) colors, I would nominate DRM. it screwed music and spurred development of P2P
- Minutus cantorum, minutus balorum, minutus carborata descendum pantorum.
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.
Can you be Even More Awesome?!
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.
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.
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.
The Kruger Dunning explains most post on
The bacteria in my digestive tract are bugs I would definitely miss.
http://alternatives.rzero.com/
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.
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.
"Never attribute to malice that which can be adequately explained by stupidity." -- Hanlon's Razor
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.
[Ego]out
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. :-)
"The human race's favorite method for being in control of the facts is to ignore them." -Celia Green
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.
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.
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.
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.
"Microsoft has made computing accessible to a population who would otherwise not be able to use computers" - B. Kernigha