3 ms·

This reminds me of fixing a bug that causes your problem but then you discover the problem persists after the fix and that you actually had two independent bugs

This reminds me of fixing a bug that causes your problem but then you discover the problem persists after the fix and that you actually had two independent bugs causing the same problem.

unnouinceput 4y ago
Erm, if you do a fix and the problem still exists then how is that a fix? For example, if I have a number box and I punch letters in it and the problem is <string "CARTER" is not a number> error is still poping up, then my fix is not a fix, is it? Regardless of how many bugs I have that cause the problem, a fix, in my opinion, is the sum of all those bugs going away.
- galaxyLogic 4y ago
  I see your point which is semantically valid. But there is something more to it. Consider it from the other direction: You can introduce a bug by making some modification to the code. Then you add another modification which produces the same erroneous behavior. Either one alone would be enough to cause the problem. And two of them together does not cause any more problems than each of them alone. But now to "fix" the problem you have to undo both of your modifications. You have 2 bugs and you have to "fix" them both. "Fix a bug" as in "Kill a bug". So "Fix a bug" can mean "remove a cause of the problem". Or it can mean "remove the problem".
  - guillaume8375 4y ago
    Your answer reminds me of “gettiers” (http://jsomers.net/blog/gettiers http://jsomers.net/blog/gettiers).
- ALittleLight 4y ago
  Obviously it'll be a bit contrived for this example, but... Suppose the logic that checked whether the input was a number used the hardcoded string "CARTER" rather than the value from the input. And, totally independent from that, your error display code just displayed the hard coded "example" value '"CARTER" is not a number' regardless of whether the state was correct or not. In this case, I would say you have two bugs. First, that you aren't evaluating the actual input data and second, that your error checking code is not running correctly but just defaulting to the same value all the time. Bugs are distinct problems with your code, not problems that the user encounters and you have two distinct problems with your code.
- krisoft 4y ago
  That is a very project managery view of things. And in a simple system you might be right. In a complex system multiple different things can cause same looking problems. Let's say you are not working on a "number box" (whatever that is) but a drone airplane. Your costumer reports that the drone become unresponsive and crashed. You investigate and find that there is a buffer overflow which sometimes gets triggered in the navigation system which trashed the memory and lead to the loss of the drone. You develop a patch, and additional testing etc etc and you deploy the fix. A year later a drone crashes again. You do the investigation and this time you find in the engine control there is an edge case which causes it to shut down the engine under rare circumstances. Was the first fix not a fix? If I correctly interpret you it wasn't because the "drone becoming unresponsive and crashing" problem still persist. Obviously that is not a useful way to look at the work if you actually have to develop the fixes. Obviously there was two different problems, and they both need fixing separately (often by different teams). Just because you are not aware of the second bug when you deploy the first fix doesn't make the first fix not a fix. Of course you might say in this hypothetical the "problem was not the same" but you only know that after you have investigated. If there are no reasons to suspect the second bug, and during the testing of the first fix things appear to be working you have no way of knowing that.
- Archelaos 4y ago
  > if you do a fix and the problem still exists then how is that a fix? The problem was fixed after the two bugs were fixed: fix(problem) <= fix(bug1) & fix(bug2)
- elliekelly 4y ago
  Have you ever had allergies and a cold at the same time?
  - 1-more 4y ago
    https://en.wikipedia.org/wiki/Hickam%27s_dictum https://en.wikipedia.org/wiki/Hickam%27s_dictum "A patient can have as many diseases as they damn well please."

This reminds me of fixing a bug that causes your problem but then you discover the problem persists after the fix and that you actually had two independent bugs causing the same problem.

unnouinceput 4y ago

Erm, if you do a fix and the problem still exists then how is that a fix? For example, if I have a number box and I punch letters in it and the problem is <string "CARTER" is not a number> error is still poping up, then my fix is not a fix, is it? Regardless of how many bugs I have that cause the problem, a fix, in my opinion, is the sum of all those bugs going away.

galaxyLogic 4y ago
I see your point which is semantically valid. But there is something more to it. Consider it from the other direction: You can introduce a bug by making some modification to the code. Then you add another modification which produces the same erroneous behavior. Either one alone would be enough to cause the problem. And two of them together does not cause any more problems than each of them alone. But now to "fix" the problem you have to undo both of your modifications. You have 2 bugs and you have to "fix" them both. "Fix a bug" as in "Kill a bug". So "Fix a bug" can mean "remove a cause of the problem". Or it can mean "remove the problem".
- guillaume8375 4y ago
  Your answer reminds me of “gettiers” (http://jsomers.net/blog/gettiers http://jsomers.net/blog/gettiers).
ALittleLight 4y ago
Obviously it'll be a bit contrived for this example, but... Suppose the logic that checked whether the input was a number used the hardcoded string "CARTER" rather than the value from the input. And, totally independent from that, your error display code just displayed the hard coded "example" value '"CARTER" is not a number' regardless of whether the state was correct or not. In this case, I would say you have two bugs. First, that you aren't evaluating the actual input data and second, that your error checking code is not running correctly but just defaulting to the same value all the time. Bugs are distinct problems with your code, not problems that the user encounters and you have two distinct problems with your code.
krisoft 4y ago
That is a very project managery view of things. And in a simple system you might be right. In a complex system multiple different things can cause same looking problems. Let's say you are not working on a "number box" (whatever that is) but a drone airplane. Your costumer reports that the drone become unresponsive and crashed. You investigate and find that there is a buffer overflow which sometimes gets triggered in the navigation system which trashed the memory and lead to the loss of the drone. You develop a patch, and additional testing etc etc and you deploy the fix. A year later a drone crashes again. You do the investigation and this time you find in the engine control there is an edge case which causes it to shut down the engine under rare circumstances. Was the first fix not a fix? If I correctly interpret you it wasn't because the "drone becoming unresponsive and crashing" problem still persist. Obviously that is not a useful way to look at the work if you actually have to develop the fixes. Obviously there was two different problems, and they both need fixing separately (often by different teams). Just because you are not aware of the second bug when you deploy the first fix doesn't make the first fix not a fix. Of course you might say in this hypothetical the "problem was not the same" but you only know that after you have investigated. If there are no reasons to suspect the second bug, and during the testing of the first fix things appear to be working you have no way of knowing that.
Archelaos 4y ago
> if you do a fix and the problem still exists then how is that a fix? The problem was fixed after the two bugs were fixed: fix(problem) <= fix(bug1) & fix(bug2)
elliekelly 4y ago
Have you ever had allergies and a cold at the same time?
- 1-more 4y ago
  https://en.wikipedia.org/wiki/Hickam%27s_dictum https://en.wikipedia.org/wiki/Hickam%27s_dictum "A patient can have as many diseases as they damn well please."