A person is tracking down a difficult problem, often one that is not completely reproducible. In a status meeting, the person announces that the problem is solved. Someone asked, "what was the cause of the problem?" The person responds, "I'm not really sure what the problem was, but I changed xyz and the problem went away, so I must have fixed it".
Nine times out of ten this approach has not really fix the problem; it just masked out the real problem. In a few weeks or months, the problem will reappear. Never assume that a problem has been corrected until you can identify the exact condition that caused the problem and convince yourself that the particular change made really explains the behavior you have seen. Ideally, you should create a test case that reliably reproduces the problem, make your fix, and then use that test case to verify that the problem is gone.
If a situation occurs, where a change was made and the problem mysteriously goes away don't stop there. Undo the change and see if the problem recurs. If the problem does not reappear then the change is probably unrelated to the problem. If undoing the change causes the problem to recur, then figure out why. For example, try reducing the scope of the change to find the smallest possible modification that causes the problem to come and go. When this does not identify the source of the problem, add additional tracing to the system and compare the "before" and "after" traces to see how the change affected the behavior of the system. Experience has proven once a condition found that makes a problem come and go most people can usually find the solution.
