5 ms·

> can't possible be interacting with your current problem The only thing not logical with programming is a programmer's ability to fully simulate the circumsta

> can't possible be interacting with your current problem The only thing not logical with programming is a programmer's ability to fully simulate the circumstances by which all bugs may occur. That ability will vary greatly from programmer to programmer. So yes, people think like this because it's easier to fix the bug than it is trying to figure out correlation.

sillysaurus3 12y ago
Maybe my previous comment was unclear. If so, sorry about that. The point was that, in programing, there is never any "figure out correlation." You can rule out whether a bug is being caused by a given line of code by examining the flow of data between what you're seeing on screen and the lines of code responsible for what is shown on that screen. A bug is never "correlated" with any given line of code. The line of code is either logically related to the bug, or not related at all. I'd be interested to hear more about how programming could be made into a correlation game, though. It sounds like a new mental tool that I've never learned, which means I should learn it.
- yummyfajitas 12y ago
  To make programming into a correlation game, build a distributed system and work on performance. You suddenly have flow of data, together with lots of external factors that are difficult to measure (e.g., a spike in latency in US-East but not US-West for 0.5% of packets, or 2% of your shared instances having a noisy neighbor). In such contexts, you usually also have a LOT of code. Correlation analysis becomes very important in figuring out which piece of code to even look at. Bugs do become "correlated" with a line of code, because bugs take the form "noisy neighbor + blocking disk read (code) + high latency to master DB => slow response".
  - sillysaurus3 12y ago
    Thank you. That's a very interesting way to think about it, and I hadn't considered that before. I apologize for making so many comments in this submission. I feel pretty terrible about it, because the number of comments are higher than the number of upvotes, which has pushed your submission off of the front page. I didn't realize it was happening until too late. But more than that, in retrospect, I should have behaved differently altogether, which would've resulted in fewer comments. Sorry.
  - kordless 12y ago
    Interesting you mentioned a distributed system. Worked on a few in the past and a fairly complicated one right now. Exactly what I was thinking when I made my comment! :)
- agarden 12y ago
  Race conditions. This bug shows up sometimes while frobbing the dingbat, but only sometimes. The crash is correlated with frobbing the dingbat.
  - scott_s 12y ago
    Very much yes. If someone tells me about a bug, and they tell me "It always happen when I do this", my immediate reaction is "Oh, good, that will be easy to fix." If instead they say, "It sometimes happens when we do this", then that means it's going to require serious investigation because we will need to start correlating different events to see under what circumstances the bug does and does not pop up. That is very much like the scientific method.
- scott_s 12y ago
  You can rarely "rule out" anything based on reasoning about data flow - simply because your reasoning always has the possibility of being flawed. If you had an oracle you could consult while debugging, you could do this. But we rarely are in that situation. Instead, you can only increase your confidence. In my experience, it is best to fix problems as you find them, even if you are confident that they are not the cause of your current bug. Each thing "wrong" I find in the code leads me to question my current mental model of what is going on. A bug means that, somewhere, there is a difference between my mental model, and what the code actually does. A seemingly unrelated error gives me evidence that my mental model may be even further from reality than I realized. That's bad. At that point, I know of at least two deviations from reality. And just like trying to establish causation in a scientific experiment, you want as few variables as possible.
  - sillysaurus3 12y ago
    I am not arguing against fixing problems. I am arguing against voodoo thinking. I'm getting the feeling that the way I learned to debug is somehow very different from what everyone else here is doing. I've never found a bug I haven't been able to fix or understand. I'm not bragging. It's simply the truth, and it's why I'm mystified about the negative reactions I'm getting here. I've spent my whole life debugging things, and I've never once ran across "maybe the bug is caused by this new problem, even though it's obviously completely unrelated, so I'm going to fix it and cross my fingers." It just seems ludicrous, the same way that it was ludicrous to think the alignment of the stars could determine whether you'll have a happy life. The oracle you consult while debugging is the program itself. If you don't understand the behavior, then you add logging statements until you do. You log everything, absolutely everything, and then reason about what the program is doing when the bug is occurring. There was exactly one bug I was never able to fix, and it was because the bug resided in closed source code (D3D9). Multithreading was triggering the bug even though their code claimed to be MT-safe. At that point, there was nothing I could do except revert to unmultithreaded shader building. It was a terrible race condition that took a full day to track down, but it didn't require any kind of correlation tricks. It simply required that I rule out large swaths of the codebase until it was logically impossible for the bug to be anywhere except in the D3D9 library. Yes, of course, fix problems as you run across them. But that's a separate discussion altogether.
- dllthomas 12y ago
  The Udacity course on debugging speaks directly to looking at correlations between bugs and executions of various portions of code (and the same across bugs). There's some interesting stuff: https://www.udacity.com/course/cs259 https://www.udacity.com/course/cs259
csbrooks 12y ago
"So yes, people think like this because it's easier to fix the bug than it is trying to figure out correlation." And many times, there's no clear advantage to figuring out the correlation first instead of just fixing the bug and seeing what happens.

sillysaurus3 12y ago

Maybe my previous comment was unclear. If so, sorry about that. The point was that, in programing, there is never any "figure out correlation." You can rule out whether a bug is being caused by a given line of code by examining the flow of data between what you're seeing on screen and the lines of code responsible for what is shown on that screen. A bug is never "correlated" with any given line of code. The line of code is either logically related to the bug, or not related at all. I'd be interested to hear more about how programming could be made into a correlation game, though. It sounds like a new mental tool that I've never learned, which means I should learn it.

yummyfajitas 12y ago
To make programming into a correlation game, build a distributed system and work on performance. You suddenly have flow of data, together with lots of external factors that are difficult to measure (e.g., a spike in latency in US-East but not US-West for 0.5% of packets, or 2% of your shared instances having a noisy neighbor). In such contexts, you usually also have a LOT of code. Correlation analysis becomes very important in figuring out which piece of code to even look at. Bugs do become "correlated" with a line of code, because bugs take the form "noisy neighbor + blocking disk read (code) + high latency to master DB => slow response".
- sillysaurus3 12y ago
  Thank you. That's a very interesting way to think about it, and I hadn't considered that before. I apologize for making so many comments in this submission. I feel pretty terrible about it, because the number of comments are higher than the number of upvotes, which has pushed your submission off of the front page. I didn't realize it was happening until too late. But more than that, in retrospect, I should have behaved differently altogether, which would've resulted in fewer comments. Sorry.
- kordless 12y ago
  Interesting you mentioned a distributed system. Worked on a few in the past and a fairly complicated one right now. Exactly what I was thinking when I made my comment! :)
agarden 12y ago
Race conditions. This bug shows up sometimes while frobbing the dingbat, but only sometimes. The crash is correlated with frobbing the dingbat.
- scott_s 12y ago
  Very much yes. If someone tells me about a bug, and they tell me "It always happen when I do this", my immediate reaction is "Oh, good, that will be easy to fix." If instead they say, "It sometimes happens when we do this", then that means it's going to require serious investigation because we will need to start correlating different events to see under what circumstances the bug does and does not pop up. That is very much like the scientific method.
scott_s 12y ago
You can rarely "rule out" anything based on reasoning about data flow - simply because your reasoning always has the possibility of being flawed. If you had an oracle you could consult while debugging, you could do this. But we rarely are in that situation. Instead, you can only increase your confidence. In my experience, it is best to fix problems as you find them, even if you are confident that they are not the cause of your current bug. Each thing "wrong" I find in the code leads me to question my current mental model of what is going on. A bug means that, somewhere, there is a difference between my mental model, and what the code actually does. A seemingly unrelated error gives me evidence that my mental model may be even further from reality than I realized. That's bad. At that point, I know of at least two deviations from reality. And just like trying to establish causation in a scientific experiment, you want as few variables as possible.
- sillysaurus3 12y ago
  I am not arguing against fixing problems. I am arguing against voodoo thinking. I'm getting the feeling that the way I learned to debug is somehow very different from what everyone else here is doing. I've never found a bug I haven't been able to fix or understand. I'm not bragging. It's simply the truth, and it's why I'm mystified about the negative reactions I'm getting here. I've spent my whole life debugging things, and I've never once ran across "maybe the bug is caused by this new problem, even though it's obviously completely unrelated, so I'm going to fix it and cross my fingers." It just seems ludicrous, the same way that it was ludicrous to think the alignment of the stars could determine whether you'll have a happy life. The oracle you consult while debugging is the program itself. If you don't understand the behavior, then you add logging statements until you do. You log everything, absolutely everything, and then reason about what the program is doing when the bug is occurring. There was exactly one bug I was never able to fix, and it was because the bug resided in closed source code (D3D9). Multithreading was triggering the bug even though their code claimed to be MT-safe. At that point, there was nothing I could do except revert to unmultithreaded shader building. It was a terrible race condition that took a full day to track down, but it didn't require any kind of correlation tricks. It simply required that I rule out large swaths of the codebase until it was logically impossible for the bug to be anywhere except in the D3D9 library. Yes, of course, fix problems as you run across them. But that's a separate discussion altogether.
dllthomas 12y ago
The Udacity course on debugging speaks directly to looking at correlations between bugs and executions of various portions of code (and the same across bugs). There's some interesting stuff: https://www.udacity.com/course/cs259 https://www.udacity.com/course/cs259

csbrooks 12y ago

"So yes, people think like this because it's easier to fix the bug than it is trying to figure out correlation." And many times, there's no clear advantage to figuring out the correlation first instead of just fixing the bug and seeing what happens.