>Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy. For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.Customer mumbles and requests the same thing as a feature request, not a bug report. They never understood what the difference was though. They couldn't print. Program bad.
Any software has a spec. It might not be publicly written, but you have in mind what you build and which features it supports. And software that's sold has lists of features, presentation pages, and trials for people to see its features.
If some random user can't tell a bug from a feature, that's on them.
Not even a development team can (or should!) be able to agree on whether something is a bug. Just because there is never a complete spec. It’s a mental state of the team. Or expectations among stakeholders.
> Any software has a spec.
Note that the 'spec' you're referring to isn't the same thing as the 'spec' in your pulled quote. The Java spec tells us that the expression
var >> 40
refers to the value var / 256
This is a bug in Java. It's not a bug in the implementation of the spec - that's what the spec says. But it is a bug in the spec.To identify that bug, you need another spec that can find fault with the official spec. Only the official spec is written down.
Here are some other common and widely-recognized bugs-in-the-spec:
- The conventional sign of the electric charge of protons and electrons has been reversed.
- Mathematical function applications are written before their argument, when they should be written after.
You must use some very small software if what it does can be held in the mind alone. Try working on something with hundreds of thousands to millions of lines of code. Have it evolve over 5 different PMs. Have it serve enterprise customers. Even something simple like
* Supports FooBaz
Now means, supports what feature set of FooBaz, what particular versions of FooBaz, does it support the fork FooBar that have the market quickly migrated to, what about the bugs in FooBaz that only show up when using your program.
Users are dumber than you think, and when they pay you a lot it's never on them.