What is the difference between ‘expected but not desired behavior’ and a software bug

It is known as a wart.

From a comment on the original post on Stack Overflow,

To be clear, this is not desired behavior, although there are good (historical) reasons for it. We (numpy devs) have preliminary plans to deprecate it in a future release, and provide easier to understand functionality that works as you might expect. See http://github.com/numpy/numpy/pull/6256 for more details. — Stephan

Every design decision is a trade off somewhere. Make something simpler somewhere, and somewhere else something may become more complicated.

Consider this bit of JavaScript:

>>> '5' + 3 - 3
50
>>> '5' - 3 + 3
5

Is that a bug? No. Is it desired behavior… eh… I don’t want to say people want it to work that way, but that’s what you get with the ‘this is how it was decided + works.’

Or in ruby that x?2:3 is a syntax error (it needs to be x ?2:3 – notice the space). Why? Because it was decided functions may end in a ? and so x?2:3 is ambiguous – a space between the variable and the ? part of the ternary expression resolves that.

Or in PhP the decision to mimic Perl’s auto-increment feature on Strings but lacking the restriction on the pattern leads to:

$foo = "3d8";
echo "$foon";
$foo++;
echo "$foon";
$foo++;
echo "$foon";
$foo++;
echo "$foon";

^(ideone)
printing out:

3d8
3d9
3e0
4

And without too much difficulty one could probably find examples of design warts in libraries and languages across the entire spectrum of software that were made that had unintended that had unintended and possibly undesired but nonetheless expected behavior.

There were indeed (debatably) good historical reasons the design decisions to make it work a certain way. And the code works that way – its not a bug, it is working exactly as intended. With the benefit of hindsight, maybe those decisions weren’t good and lead to undesired behavior, but the code is working as intended – there isn’t a bug there, its a wart.

^{While I have listed a few warts that I can quickly show and tickle, there are countless ones out there. I really don’t need more examples. I would frankly be surprised if one were to find a language or library that doesn’t contain a wart.}

A “bug” is an informal term for a defect in the software. It usually refers to something wrong in the code. If you want to use formal terms, you would want to use words like “error” (a human action or inaction that led to an incorrect result), “fault” or “defect” (a wrong step, process, or definition), and “failure” (an inaccurate result). An error will lead to a fault or defect that can manifest itself as a failure. This answer by dukeofgaming (along with other answers in that question) is a good explanation of the difference between defects, failures, and bugs.

These terms can be applied to more than just source code. For example, an error made in your requirements can manifest as a defect in your design. If a user sees this behavior, they may interpret it as a failure, even if your testing doesn’t. Your software code could be a reflection of your understanding of your requirements, but that understanding is incorrect. This sounds very much like what happened in your situation – the software is behaving as the developers intended it to. Still, their intentions and the expectations of the users did not align.

The difference is that “bug” implies the software is doing something wrong, and that it should be able to do that thing better than it currently is.

Most undesirable behaviors that I would not consider bugs would fall into one of these categories:

• A flaw that’s inherent in the nature of the application, and simply cannot be avoided. Your mobile phone’s browser may take a long time to load a web page when you have a very weak cell signal. It may also display vulgar, offensive, or just plain irritating content that you did not want to see. In general, these are not problems the browser can ever completely solve.
• A tradeoff with another design goal. Many programming languages allow floating point numbers to have rounding error, because doing all their math with arbitrary-precision arithmetic would be too performance intensive. There have been many arguments about which rounding errors do and do not qualify as bugs.
• A simple mistake in the design that, for whatever reason, is no longer feasible to change.
• A flaw, tradeoff or design error in the specification that a program needs to conform to. Most C++ compilers will allow you to compile code that is very obviously broken, because otherwise they wouldn’t be conformant to the C++ Standard.

I don’t fully understand the numpy array indexing issue you’ve linked to, but it sounds like it’s in the third category.

A bug would be behaviour that appears because someone, somewhere made a mistake. It might be the UI designer who told the developers to implement wrong behaviour, it might be a developer making a mistake, or the compiler.

On the other hand, if it was decided that the action for some button will not be implemented because it’s too much cost and effort for the gain, that’s certainly undesired behaviour, but it is intentional, not a bug.

A bug is when the user-observable behavior differs from the documented behavior. An undesired behavior is when the user-observable behavior correctly corresponds to the documented behavior, but you would rather like to have a different behavior.

• “Bug”: the system doesn’t do what it promises
• “Undesired behavior”: the system makes stupid promises