5 ms·

What proof is all around us?

fidotron 3y ago
The amount of software in everyday objects which runs without exhibiting bugs to such a degree we do not notice most of it even exists.
- sanderjd 3y ago
  Yes, but that software is not bug-free. The claim was not "it's impossible to make software that does not exhibit bugs too a casually noticeable degree". People who know how the sausage is made will always know of a bunch of bugs that haven't been fixed exactly because they aren't impactful enough to be worth the effort required to fix them.
  - fidotron 3y ago
    If it works within specs it is bug free. It doesn’t matter how it is made if it works within specs, which is one of the real unfortunate truths of software. The other is working out the correct specification is far harder than coding is. For example it is trivial to write a bug free program that multiplies an integer between 3 and 45 by two.
    - digging 3y ago
      > If it works within specs it is bug free. No, it's functional. If it has bugs, it's not bug-free. By definition.
      - fidotron 3y ago
        What would it mean to be bug free then? To quote a former marketing guy “it should work out what the user intends to do and do it”?
        digging 3y ago
        To have no bugs, which is extremely unlikely for a program of any real complexity. Having bugs, and being functional, are fairly self-explanatory and independent of each other. No need to try to conflate them. Not sure what your quote is supposed to mean. That's a textbook example of someone who doesn't understand software at all making laughable requests of their engineers.
        fidotron 3y ago
        To be bug free we must be able to define what a bug is. So, what is a bug? The reason for that quote is from what you have said a bug would be anything you didn't expect, even if it is consistent or not with the specification as that merely affects if we classify it as functional or not (a classification I profoundly disagree with, obviously). It is simply a negative rephrasing of what the marketing guy said and laughable in the same way.
        digging 3y ago
        As another commenter pointed out, > One plausible definition is “system deviates from its specification” And that's quite reasonable. So I actually retract my argument. For my own definition, I was considering a bug to be any behavior that the software engineers weren't expecting. Because those can exist invisibly for a long time until they become so bad they become visible. They can also exist for decades without causing any problems to functionality at all.
        ponector 3y ago
        Bug free software means developers would not disclose any information about present bugs in the software they ship to customers. Really bug free commercial software does not exist. And can't exist. There are always bugs which are known but would not be fixed.
      - tonyarkles 3y ago
        Not to get too meta here but… what is your definition of a bug? One plausible definition is “system deviates from its specification”.
        digging 3y ago
        Fair enough. I considered a bug to be any behavior the engineers didn't plan in the code. They have their own specification, in their heads, that is more technical/exact than the business specification. Your definition is also reasonable but it's not what people mean when they say "there's no such thing as bug-free code", because bugs of my definition are almost unavoidable.
    - bluGill 3y ago
      Most devices work within the spec 99.9% of the time, but that last .1% it is outside the spec. The exact % is different for different projects of course, but the idea is still there: no software operates according to spec 100% of the time.
      - fidotron 3y ago
        It does though. My example of adding two ints within a known finite range would operate to spec 100% of the time. You would have to introduce things like tolerance to hardware failure, but that is outside the spec of the software as stated.
        sanderjd 3y ago
        Yes, but that's not real software.
        fidotron 3y ago
        https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman
        sanderjd 3y ago
        Some people obviously aren't true Scotsman... I'm from the US and have no attachment to Scotland; if I claimed to be a Scotsman and you pointed out that I'm not, and I said "well that's just the no true Scotsman fallacy!", then I would be totally full of it. In the same way I am not a real Scotsman, your toy example of an easily specified snippet of a function that doesn't do anything useful is not real software.
        bluGill 3y ago
        Sure, but adding two ints is trivial. Hello world probably operates to spec all the time too. Almost all software is vastly more compelx and isn't perfect.
        philipwhiuk 3y ago
    - ponector 3y ago
      You know, there could be bugs in spec. And you can have a software written with bugs but according to spec. When testing should start? BEFORE the first line of code is written.
    - sanderjd 3y ago
      As you alluded, in practice no specs fully specify a truly bug free implementation. If you want to consider bugs that are within the specification as being bugs in the spec rather than bugs in the implementation, fine, but in my view that is a distinction without a difference. (Personally, I think code is itself more analogous to the specification artifacts of other professions - eg. blueprints - and the process of creating the machine code of what is analogous to construction / manufacturing something to those specs.) And even having said that, even the vast majority "bug free" software that nearly always appears to be operating "within spec" will have corner cases that are expressed in very rare situations. But none of this is an argument for nihilism about quality! It is just not the right expectation going into a career in software that you'll be able to make things that are truly perfect. I have seen many people struggle with that expectation mismatch and get lost down rabbit holes of analysis paralysis and overengineering because of it.
      - fidotron 3y ago
        > in practice no specs fully specify a truly bug free implementation. Except for ones that do, obviously. The key reason to make the distinction is because the fuzzy business of translating intention into specification needs to be fully accepted as an ongoing negotiation process of defining exactly what the specification is, and integrated into repeated deterministic verification that that is what has been delivered. Failing to do that is mainly a great way for certain software management structures to manipulate people by ensuring everything is negotiable all the time, and has the side effect that no one can even say if something is a bug or not. (And this pattern is very clear in the discussion in this thread - there is a definite unwillingness to define what a bug is). IME the process of automated fuzzing radically improves all round quality simply because it shakes out so many of the implicit assumptions and forces you specify the exact expected results. The simple truth is most people are too lazy and/or lack the discipline needed to do it.
        sanderjd 3y ago
        Those don't exist. There are too many free variables. Some get much closer than others (for instance via formal verification), but all specs are by necessity a model of reality, not the full reality itself. Nobody actually has any trouble knowing what a bug is. Like, this is just a non-issue, I've never in my career spent a non-negligible amount of time debating with anybody whether something is or isn't a bug. We discuss whether fixing bugs have worthwhile return on investment, and we discuss the relative priority between fixing bugs and doing other things, but this meta-debate about "well technically it complies with this spec so is it even a bug, really?" just never comes up. We all know what bugs are.
- avgDev 3y ago
  There are people PUTTING out fires nonstop in many apps we all use. I have been writing code for almost a decade now, and still make errors. I don't believe anyone is capable of producing bug free software. I have also seen plenty of bugs in apps and games. I don't think I have ever witnessed a major game patch that was bug free.
- ponector 3y ago
  I encounter bugs everywhere all time. List goes very long. Microwave has random errors from time to time. Robo vacuum freezes. Parking meter malfunction. Public transport ticket machine don't want to give me a ticket. Online banking failing to make a transfer because I use UI with other language. Mobile banking failing to make a transfer because I use not native currency. Car has issues as well, incorrect fuel amount is injected by computer. Online pages have tons of bugs, many are barely usable.

The amount of software in everyday objects which runs without exhibiting bugs to such a degree we do not notice most of it even exists.

sanderjd 3y ago
Yes, but that software is not bug-free. The claim was not "it's impossible to make software that does not exhibit bugs too a casually noticeable degree". People who know how the sausage is made will always know of a bunch of bugs that haven't been fixed exactly because they aren't impactful enough to be worth the effort required to fix them.
- fidotron 3y ago
  If it works within specs it is bug free. It doesn’t matter how it is made if it works within specs, which is one of the real unfortunate truths of software. The other is working out the correct specification is far harder than coding is. For example it is trivial to write a bug free program that multiplies an integer between 3 and 45 by two.
  - digging 3y ago
    > If it works within specs it is bug free. No, it's functional. If it has bugs, it's not bug-free. By definition.
    - fidotron 3y ago
      What would it mean to be bug free then? To quote a former marketing guy “it should work out what the user intends to do and do it”?
      - digging 3y ago
        To have no bugs, which is extremely unlikely for a program of any real complexity. Having bugs, and being functional, are fairly self-explanatory and independent of each other. No need to try to conflate them. Not sure what your quote is supposed to mean. That's a textbook example of someone who doesn't understand software at all making laughable requests of their engineers.
        fidotron 3y ago
        To be bug free we must be able to define what a bug is. So, what is a bug? The reason for that quote is from what you have said a bug would be anything you didn't expect, even if it is consistent or not with the specification as that merely affects if we classify it as functional or not (a classification I profoundly disagree with, obviously). It is simply a negative rephrasing of what the marketing guy said and laughable in the same way.
        digging 3y ago
        As another commenter pointed out, > One plausible definition is “system deviates from its specification” And that's quite reasonable. So I actually retract my argument. For my own definition, I was considering a bug to be any behavior that the software engineers weren't expecting. Because those can exist invisibly for a long time until they become so bad they become visible. They can also exist for decades without causing any problems to functionality at all.
      - ponector 3y ago
        Bug free software means developers would not disclose any information about present bugs in the software they ship to customers. Really bug free commercial software does not exist. And can't exist. There are always bugs which are known but would not be fixed.
    - tonyarkles 3y ago
      Not to get too meta here but… what is your definition of a bug? One plausible definition is “system deviates from its specification”.
      - digging 3y ago
        Fair enough. I considered a bug to be any behavior the engineers didn't plan in the code. They have their own specification, in their heads, that is more technical/exact than the business specification. Your definition is also reasonable but it's not what people mean when they say "there's no such thing as bug-free code", because bugs of my definition are almost unavoidable.
  - bluGill 3y ago
    Most devices work within the spec 99.9% of the time, but that last .1% it is outside the spec. The exact % is different for different projects of course, but the idea is still there: no software operates according to spec 100% of the time.
    - fidotron 3y ago
      It does though. My example of adding two ints within a known finite range would operate to spec 100% of the time. You would have to introduce things like tolerance to hardware failure, but that is outside the spec of the software as stated.
      - sanderjd 3y ago
        Yes, but that's not real software.
        fidotron 3y ago
        https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman
        sanderjd 3y ago
        Some people obviously aren't true Scotsman... I'm from the US and have no attachment to Scotland; if I claimed to be a Scotsman and you pointed out that I'm not, and I said "well that's just the no true Scotsman fallacy!", then I would be totally full of it. In the same way I am not a real Scotsman, your toy example of an easily specified snippet of a function that doesn't do anything useful is not real software.
      - bluGill 3y ago
        Sure, but adding two ints is trivial. Hello world probably operates to spec all the time too. Almost all software is vastly more compelx and isn't perfect.
      - philipwhiuk 3y ago
  - ponector 3y ago
    You know, there could be bugs in spec. And you can have a software written with bugs but according to spec. When testing should start? BEFORE the first line of code is written.
  - sanderjd 3y ago
    As you alluded, in practice no specs fully specify a truly bug free implementation. If you want to consider bugs that are within the specification as being bugs in the spec rather than bugs in the implementation, fine, but in my view that is a distinction without a difference. (Personally, I think code is itself more analogous to the specification artifacts of other professions - eg. blueprints - and the process of creating the machine code of what is analogous to construction / manufacturing something to those specs.) And even having said that, even the vast majority "bug free" software that nearly always appears to be operating "within spec" will have corner cases that are expressed in very rare situations. But none of this is an argument for nihilism about quality! It is just not the right expectation going into a career in software that you'll be able to make things that are truly perfect. I have seen many people struggle with that expectation mismatch and get lost down rabbit holes of analysis paralysis and overengineering because of it.
    - fidotron 3y ago
      > in practice no specs fully specify a truly bug free implementation. Except for ones that do, obviously. The key reason to make the distinction is because the fuzzy business of translating intention into specification needs to be fully accepted as an ongoing negotiation process of defining exactly what the specification is, and integrated into repeated deterministic verification that that is what has been delivered. Failing to do that is mainly a great way for certain software management structures to manipulate people by ensuring everything is negotiable all the time, and has the side effect that no one can even say if something is a bug or not. (And this pattern is very clear in the discussion in this thread - there is a definite unwillingness to define what a bug is). IME the process of automated fuzzing radically improves all round quality simply because it shakes out so many of the implicit assumptions and forces you specify the exact expected results. The simple truth is most people are too lazy and/or lack the discipline needed to do it.
      - sanderjd 3y ago
        Those don't exist. There are too many free variables. Some get much closer than others (for instance via formal verification), but all specs are by necessity a model of reality, not the full reality itself. Nobody actually has any trouble knowing what a bug is. Like, this is just a non-issue, I've never in my career spent a non-negligible amount of time debating with anybody whether something is or isn't a bug. We discuss whether fixing bugs have worthwhile return on investment, and we discuss the relative priority between fixing bugs and doing other things, but this meta-debate about "well technically it complies with this spec so is it even a bug, really?" just never comes up. We all know what bugs are.
avgDev 3y ago
There are people PUTTING out fires nonstop in many apps we all use. I have been writing code for almost a decade now, and still make errors. I don't believe anyone is capable of producing bug free software. I have also seen plenty of bugs in apps and games. I don't think I have ever witnessed a major game patch that was bug free.
ponector 3y ago
I encounter bugs everywhere all time. List goes very long. Microwave has random errors from time to time. Robo vacuum freezes. Parking meter malfunction. Public transport ticket machine don't want to give me a ticket. Online banking failing to make a transfer because I use UI with other language. Mobile banking failing to make a transfer because I use not native currency. Car has issues as well, incorrect fuel amount is injected by computer. Online pages have tons of bugs, many are barely usable.