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.
Now you implement the printing feature. There is an infinity of things to handle there. You add the 99.9% case which is basically regular printers, perhaps normal paper sizes. You however don't throw in things like document splitting (sending different pages to different devices based on capability). You have to stop somewhere. None of this is specified, however. None of the limitations are communicated to users. But you added the feature - in some sense. Then a customer with a 1970's pen plotter files a bug report that your new feature doesn't work on his device. Will you fix his bug? He's the only one on the planet with the problem. Is it a bug or a new feature? To him it's _clearly_ a bug. To you it would _clearly_ be a new feature to support pen plotting. You could argue the semantics of whether this is a bug or a feature until the sun goes down and it doesn't really matter. Either the fixed bug/added feature has enough value to be done, or it doesn't.
A key takeaway here: this isn't merely something that appears in the perspective of the user vs the developer. The argument about whether you actually have a "Bug" because you stopped short of implementing every kind of printing known to man is one you could have with your PM too. He likely didn't even consider that. But does that make it not a bug?
There is a pretty clear and important difference between a program that does something wrong, and a program that just doesn't do something somebody wants.
"You don't support printing", "pressing the print button doesn't print", "pressing the print button crashes the computer" and "pressing the print button lets an attacker get root access to the system" are all different and it makes sense to distinguish them. (The first is a missing feature, the second and third are different kinds of bugs, the last is a special kind of bug we call a security vulnerability.)
That distinction might not be useful to end-users, but it's useful for the people building the system! If you want to care about quality, committing to a strategy like "we will not add features before we fix known bugs" is totally clear, reasonable and effective. There might be some frontier of issues where it's hard to make a distinction, but that just means there are subtle edge-cases, not that the whole concept is undefined. A lot of perfectly cromulent concepts have edge-cases! You can just decide those on a case-by-case basis; if it's actually so close as to be legitimately confusing—it's not just feigned ignorance or political posturing—which side you choose probably doesn't have much of an effect.
This does depend on having a reasonably clear idea of what you're building, but that "reasonably clear idea" does not have to be anywhere near the detail of a "full spec", much less anything formalized. To me, that seems like a baseline you'd need to build quality software at all, and hardly an unreasonable thing to expect. And if most teams can't manage, well, it's just another explanation for why most software is crap.
> There is a pretty clear and important difference between a program that does something wrong, and a program that just doesn't do something somebody wants.
Your argument hinges on all parties agreeing on what "wrong" means. Take a step back and consider that parties do not agree on a common definition of "wrong." Does "wrong" mean a gap between the spec and the implementation or a gap between a reasonable user's expectation and the implementation? If one party assert that it is clearly the former and the other party asserts it is clearly the latter, does that make the situation more clear or less clear?
Just because you can't get everyone to agree does not mean that the concept is not well-defined or clear. People can and do disagree over almost anything. That could just mean that one side is wrong and the other side is right, even if it is difficult to determine which is which... or simply difficult to navigate the underlying politics regardless.
Besides, in your example, either kind of gap could be a bug or a missing feature. It's a totally orthogonal question.
There are some really obvious things that are definitely bugs. If login doesn’t work if your email address contains the letter “e” when the expectation is all valid email addresses should work, then that is a bug. It isn’t “indistinguishable from a feature”. If clicking a button in your accounting software consumes all the RAM on your computer and causes it to crash, then there is no universe or agreed upon definition that would consider that a feature instead of a bug.
>If login doesn’t work if your email address contains the letter “e” when the expectation is all valid email addresses should work,
And what about the + symbol?
>Your argument hinges on all parties agreeing on what "wrong" means
No, it just hinges on common sense. "All parties" are never gonna agree on everything.
There will always be customers that demand whatever and treats its lack as a bug. Doesn't make it a bug anymore than me asking for a free glass of wine with my meal and not being given any is "injustice" - when the restaurant never promised any.
>No, it just hinges on common sense
Common sense doesn't exist in the business environment.
Sure it does. To a point, as all things. One could always have more, but it is what it is.
What party would desire to crash a program
An unuseful-in-99%-of-cases definition of bug would be "any behavior that is not in the spec is a bug". But that would mean not shipping fast and breaking things. And having a spec.
> 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.
As a sidenote, I dislike it when a vendor makes me care whether something is a bug report, feature request, or support query prior to filing it. I'm willing to make an assessment on whether the query is of a public or private (if I'm unwilling to publish publicly, sensitive customer info, potential for vuln et c.) nature but beyond that I don't want to spend any time arguing about classification.
>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.
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.
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
refers to the value 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.