5 ms·

what do you mean "there is no way to distinguish a feature from a bug"? of course there is

jihadjihad 3mo ago
I read it as an argument from the end user’s perspective. Kind of like this: - trying to do X, getting software error: bug - wishing the software did Y, even though it’s not implemented: bug Indeed there are people who think like that, but usually they are people like my grandparents, whose level of software understanding boils down to “the Desktop is where I play Solitaire” and “Internet Explorer is the literal internet”.
- alkonaut 3mo ago
  That's the simple version of it yes. I outlined a more complex version of it in a parallel answer. In short: lacking a complete specification of what to do, it's often impossible even within software teams to tell whether something is a bug. And you never have a complete specification of what to do.
- coldtea 3mo ago
  >an argument from the end user’s perspective Well, the end user's perspective is buggy. And a developer doesn't have to give the same semantics as the user, anymore than a medical equipment manufactured needs to consider its products based on what each random patient wants and what misconceptions or urban legends they believe.
alkonaut 3mo ago
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?
- tikhonj 3mo ago
  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.
  - dopple 3mo ago
    > 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?
    - 3mo ago
onion2k 3mo ago
A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code. It's a correct statement, but when you're talking about memory safe languages it's true that memory safety helps you avoid writing code that doesn't do what you were expecting, so I'd still suggest memory safety matters for reducing the number of bugs.
- witx 3mo ago
  > A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code. You're twisting very hard the definitions here. A bug is a behaviour different than the one intended, it is not tied to code whatsoever. You can have bugs "in the code" that happen because of faulty hardware, or a solar flare. Unless you work in an industry where solar flares should be taken into consideration, the code and requirement can match and you still have the (protential) bug

I read it as an argument from the end user’s perspective. Kind of like this: - trying to do X, getting software error: bug - wishing the software did Y, even though it’s not implemented: bug Indeed there are people who think like that, but usually they are people like my grandparents, whose level of software understanding boils down to “the Desktop is where I play Solitaire” and “Internet Explorer is the literal internet”.

alkonaut 3mo ago
That's the simple version of it yes. I outlined a more complex version of it in a parallel answer. In short: lacking a complete specification of what to do, it's often impossible even within software teams to tell whether something is a bug. And you never have a complete specification of what to do.
coldtea 3mo ago
>an argument from the end user’s perspective Well, the end user's perspective is buggy. And a developer doesn't have to give the same semantics as the user, anymore than a medical equipment manufactured needs to consider its products based on what each random patient wants and what misconceptions or urban legends they believe.

alkonaut 3mo ago

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?

tikhonj 3mo ago
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.
- dopple 3mo ago
  > 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?
  - 3mo ago

onion2k 3mo ago

A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code. It's a correct statement, but when you're talking about memory safe languages it's true that memory safety helps you avoid writing code that doesn't do what you were expecting, so I'd still suggest memory safety matters for reducing the number of bugs.

witx 3mo ago
> A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code. You're twisting very hard the definitions here. A bug is a behaviour different than the one intended, it is not tied to code whatsoever. You can have bugs "in the code" that happen because of faulty hardware, or a solar flare. Unless you work in an industry where solar flares should be taken into consideration, the code and requirement can match and you still have the (protential) bug