13 ms·

If you find a bug like he did, and it's easy to fix and unlikely to break something else, but you can't reason how it could be causing the issue you're seeing,

If you find a bug like he did, and it's easy to fix and unlikely to break something else, but you can't reason how it could be causing the issue you're seeing, FIX IT ANYWAY. It's quite possible it's interacting in some subtle way with another bug Do people really reason like this? I mean, programming is absolutely clear-cut. It's the most clear-cut aspect of life, in some ways. It's purely a logic problem. If you see something that can't possibly be interacting with your problem, then spending additional mental cycles on it is always a waste of your time for solving that problem. Now, it may be a good idea to fix that new problem. That's perfectly true. But if it can't possibly affect your current problem, then fixing the new problem won't do a darn thing to help you fix your current problem. That sounds like tautology, but your comment is saying the opposite. You can prove to yourself that a new problem can't possibly be interacting with your current problem. If the problems exist in two separate modules, you look at the connections between the modules and see whether any data can possibly flow from one to the other. If there is no state that flows between them, then the problems are necessarily independent. I think what you're saying is that "most codebases suck, because they have a lot of interdependencies and are hard to analyze." That's probably true. But resorting to voodoo thinking isn't going to help.

kordless 12y ago
> 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.
- 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.
csbrooks 12y ago
"In theory, theory is a lot like practice. In practice, practice is nothing like theory."
ElliotH 12y ago
But in most real codebases separate units don't interact cleanly. "you look at the connections between the modules and see whether any data can possibly flow from one to the other." is something that would be very hard to do in codebases that aren't perfect. Probably more of a waste of the mental cycles than just putting it right if it is a quick fix. With version control you can even avoid the problems of making the original problem worse with your fix.
CWuestefeld 12y ago
While I don't completely agree with the parent post, I don't think that your reply does it justice. If you see something that can't possibly be interacting with your problem... I think that "can't possibly" is the source of trouble. Today it's practically impossible to say with certainty what is actually impossible. There's so much going on at a lower level that's not visible to us, from network routing completely outside our systems, to the internal workings of many large APIs and frameworks, that there's plenty of room for things to happen in ways that are unlikely to us, but in retrospect after we've researched, do fit together.
- sillysaurus3 12y ago
  I guess I just assumed that everyone researches everything. Doesn't everyone look into how network routing works, or how every large API or framework is implemented, etc? If you're running into a bug, and that bug can possibly be affected by any of those things, then you have to dive all the way to the bottom of the swimming pool to see if there's something amiss.
  - scott_s 12y ago
    Yes, we do that. But we also have learned, the hard way, to have some humility with that knowledge. Something may disagree with our mental model, but we're careful not to say something is impossible because our mental model may be wrong. (In fact, it is wrong, since we're dealing with a bug.)
GotAnyMegadeth 12y ago
When I first started programming every single bug was caused by something that couldn't possibly be related to the problem...

kordless 12y ago

> 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.
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.

csbrooks 12y ago

"In theory, theory is a lot like practice. In practice, practice is nothing like theory."

ElliotH 12y ago

But in most real codebases separate units don't interact cleanly. "you look at the connections between the modules and see whether any data can possibly flow from one to the other." is something that would be very hard to do in codebases that aren't perfect. Probably more of a waste of the mental cycles than just putting it right if it is a quick fix. With version control you can even avoid the problems of making the original problem worse with your fix.

CWuestefeld 12y ago

While I don't completely agree with the parent post, I don't think that your reply does it justice. If you see something that can't possibly be interacting with your problem... I think that "can't possibly" is the source of trouble. Today it's practically impossible to say with certainty what is actually impossible. There's so much going on at a lower level that's not visible to us, from network routing completely outside our systems, to the internal workings of many large APIs and frameworks, that there's plenty of room for things to happen in ways that are unlikely to us, but in retrospect after we've researched, do fit together.

sillysaurus3 12y ago
I guess I just assumed that everyone researches everything. Doesn't everyone look into how network routing works, or how every large API or framework is implemented, etc? If you're running into a bug, and that bug can possibly be affected by any of those things, then you have to dive all the way to the bottom of the swimming pool to see if there's something amiss.
- scott_s 12y ago
  Yes, we do that. But we also have learned, the hard way, to have some humility with that knowledge. Something may disagree with our mental model, but we're careful not to say something is impossible because our mental model may be wrong. (In fact, it is wrong, since we're dealing with a bug.)

GotAnyMegadeth 12y ago

When I first started programming every single bug was caused by something that couldn't possibly be related to the problem...