6 ms·

I consider a "bug" to be "it was supposed to do something and failed". Issues around business logic are not failures of the system, the system worked to spec,

I consider a "bug" to be "it was supposed to do something and failed". Issues around business logic are not failures of the system, the system worked to spec, the spec was not comprehensive enough and now we iterate.

repelsteeltje 3y ago
...And now we could probably start debating your narrow definition of "system". ;-)
- pipo234 3y ago
  Most of the software I've built doesn't have "a spec.", but let me zoom in on specs. around streaming media. MPEG DASH, CMAF or even the base media file format (ISO/IEC 14496-12) at times can be pretty vague. In practice, this frequently turns up in actual interoperability issues where it's pretty difficult to point out which of two products is according to spec and which one has a bug. So yes, I totally agree with GP and would actually go further: a phrase like "we found all the bugs in the database" is nonsense and makes the article less credible.
Aachen 3y ago
What do you call it when the spec is wrong? Like clearly actually wrong, such as when someone copied a paragraph from one CRUD-describing page to the next and forgot to change the word "thing1" to "thing2" in the delete description. Because I'd call that a bug. A spec bug, but a bug. It's no feature request to make the code based on the newer page delete thing2 rather than thing1, it's fixing a defect
- deleted 3y ago
  [deleted]
- pinkmuffinere 3y ago
  Ya, I would like a word for this as well. I naturally refer to this category of error as bug, but this occasionally leads to significant conflict with others at work. I now default to calling _almost everything_ a feature request, which is obviously dumb but less likely to get me into trouble. If there is a better word for "it does exactly what we planned, but what we planned was wrong" I would love to adopt it.
  - Aachen 3y ago
    I reported such a bug to some software my company uses (Tempo). Vendor proceeds to call it a feature request because the software successfully fails to show public information (visible in the UI, but HTTP 403 in the API unless you're an admin). Instead of changing one word in the code that defines the access level required for this GET call, it gets triaged as not being a bug, put on a backlog, and we never heard from it again obviously We pay for this shit
    - pinkmuffinere 3y ago
      Successful failure is my favorite kind, I like to think that all my failures are successful
- SilasX 3y ago
  There’s the distinction between correctness and fitness for purpose which I think is helpful for clarifying the issues here. Correctness bug: it didn’t do what the spec says it should do. Fitness for purpose bug: it does what the spec says to do, but, with better knowledge, the spec isn’t what you actually want. Edit: looks like this maps, respectively, to failing verification and failing validation. https://news.ycombinator.com/item?id=39359673 https://news.ycombinator.com/item?id=39359673 Edit2: My earlier comment on the different things that get called "bugs", before I was aware of this terminology: https://news.ycombinator.com/item?id=22259973 https://news.ycombinator.com/item?id=22259973
rkangel 3y ago
Systems Engineering has terminology for this distinction. Verification is "does this thing do what I asked it to do". Validation is "did I ask it to do the right thing".
- crashabr 3y ago
  Tangentially related, but I've recently started distinguishing verification and validation in my data cleaning work: verification refers to "is this dataset clean?" or the more precise "does this dataset confirm my assumptions about what a what a correct dataset should be given its focus" validation refers to "can it answer my questions?" or the more rigorous "can I test my hypotheses against this dataset?" So I find this interesting (but in hindsight unsurprising) that similar definitions are used in other fields. Would you have a source for your defintions?
  - rkangel 3y ago
    They're fairly standard terms from "old style" project management - they show up in the usual V Model of Waterfall vein. E.g. see Wikipedia: https://en.m.wikipedia.org/wiki/Verification_and_validation https://en.m.wikipedia.org/wiki/Verification_and_validation
zestyping 3y ago
A spec bug is just as bad as a code bug! Declaring a system free of defects because it matches the spec is sneaky sleight-of-hand that ignores the costs of having a spec. The actual testing value is the difference between the cost of writing and maintaining the code, and the cost of writing and maintaining the spec. If the spec is similar in complexity to the code itself, then bugs in the spec are just as likely as bugs in the code, thus verification to spec has gained you nothing (and probably cost you a lot).
cortesoft 3y ago
I agree they are separate, but in my long experience, spec bugs are at least as common as your first definition.

repelsteeltje 3y ago

...And now we could probably start debating your narrow definition of "system". ;-)

pipo234 3y ago
Most of the software I've built doesn't have "a spec.", but let me zoom in on specs. around streaming media. MPEG DASH, CMAF or even the base media file format (ISO/IEC 14496-12) at times can be pretty vague. In practice, this frequently turns up in actual interoperability issues where it's pretty difficult to point out which of two products is according to spec and which one has a bug. So yes, I totally agree with GP and would actually go further: a phrase like "we found all the bugs in the database" is nonsense and makes the article less credible.

Aachen 3y ago

What do you call it when the spec is wrong? Like clearly actually wrong, such as when someone copied a paragraph from one CRUD-describing page to the next and forgot to change the word "thing1" to "thing2" in the delete description. Because I'd call that a bug. A spec bug, but a bug. It's no feature request to make the code based on the newer page delete thing2 rather than thing1, it's fixing a defect

deleted 3y ago
[deleted]
pinkmuffinere 3y ago
Ya, I would like a word for this as well. I naturally refer to this category of error as bug, but this occasionally leads to significant conflict with others at work. I now default to calling _almost everything_ a feature request, which is obviously dumb but less likely to get me into trouble. If there is a better word for "it does exactly what we planned, but what we planned was wrong" I would love to adopt it.
- Aachen 3y ago
  I reported such a bug to some software my company uses (Tempo). Vendor proceeds to call it a feature request because the software successfully fails to show public information (visible in the UI, but HTTP 403 in the API unless you're an admin). Instead of changing one word in the code that defines the access level required for this GET call, it gets triaged as not being a bug, put on a backlog, and we never heard from it again obviously We pay for this shit
  - pinkmuffinere 3y ago
    Successful failure is my favorite kind, I like to think that all my failures are successful
SilasX 3y ago
There’s the distinction between correctness and fitness for purpose which I think is helpful for clarifying the issues here. Correctness bug: it didn’t do what the spec says it should do. Fitness for purpose bug: it does what the spec says to do, but, with better knowledge, the spec isn’t what you actually want. Edit: looks like this maps, respectively, to failing verification and failing validation. https://news.ycombinator.com/item?id=39359673 https://news.ycombinator.com/item?id=39359673 Edit2: My earlier comment on the different things that get called "bugs", before I was aware of this terminology: https://news.ycombinator.com/item?id=22259973 https://news.ycombinator.com/item?id=22259973

rkangel 3y ago

Systems Engineering has terminology for this distinction. Verification is "does this thing do what I asked it to do". Validation is "did I ask it to do the right thing".

crashabr 3y ago
Tangentially related, but I've recently started distinguishing verification and validation in my data cleaning work: verification refers to "is this dataset clean?" or the more precise "does this dataset confirm my assumptions about what a what a correct dataset should be given its focus" validation refers to "can it answer my questions?" or the more rigorous "can I test my hypotheses against this dataset?" So I find this interesting (but in hindsight unsurprising) that similar definitions are used in other fields. Would you have a source for your defintions?
- rkangel 3y ago
  They're fairly standard terms from "old style" project management - they show up in the usual V Model of Waterfall vein. E.g. see Wikipedia: https://en.m.wikipedia.org/wiki/Verification_and_validation https://en.m.wikipedia.org/wiki/Verification_and_validation

zestyping 3y ago

A spec bug is just as bad as a code bug! Declaring a system free of defects because it matches the spec is sneaky sleight-of-hand that ignores the costs of having a spec. The actual testing value is the difference between the cost of writing and maintaining the code, and the cost of writing and maintaining the spec. If the spec is similar in complexity to the code itself, then bugs in the spec are just as likely as bugs in the code, thus verification to spec has gained you nothing (and probably cost you a lot).

cortesoft 3y ago

I agree they are separate, but in my long experience, spec bugs are at least as common as your first definition.