You are testing some code that you just wrote, and you encounter a bug that you haven't seen before and that can't possibly be related to anything you're doing.  Stop right there.  You just made some changes.  You now see a bug that you didn't see before.  No matter how unrelated the bug seems to the changes you just made, almost certainly ''ItWasSomethingYouJustDid''.

This is a special case of BlameYourselfFirst.
----

I have a program with two bugs. I can't see the first because the second masks it. I fix the second. Now I encounter a bug I haven't seen before - the first. Thinking it was something I just did, I become stressed.

I have a program with two bugs. I can't see the first because the second masks it. I fix the second. Now I encounter a bug I haven't seen before - the first. I don't assume it was something I just did. Following the DebuggingPatternLanguage I find it. I am not stressed.

Seems to me the second is the way to go. Blame isn't good for anyone, yourself included. DontBlameJustDo. --PeterMerel.

The code you just wrote is far easier to check for bugs than code you wrote days or months ago, and it's much, much easier to debug than code somebody else wrote months ago and you've never even seen before.  Since it's also likely that the bug you're looking for is in that new code, it makes sense to check it thoroughly ''before'' you go assuming that the problem is elsewhere.  There's no blame involved in suspecting that the code you just wrote has bugs in it -- that's just the way of things.  Going on a long goose chase into other parts of the system before you thorougly checked the code you just wrote, now that might be cause for blame...  -- CurtisBartley

Oh, quite right. Indeed this ought to be part of the DebuggingPatternLanguage. But you can't assume, as the original comment on this page suggests, that what you're seeing is "almost certainly" the result of what you did. All I'm really saying is that impartiality is important to this; assuming nothing, diagnosis can proceed rapidly. --PeterMerel

In the examples give, however, the behavior was the result of something I just did.  Blaming is a wasted step, but assuming that what I just did is in some way related to the problem is valid - I just fixed the bug that masked another. Something in what I changed has caused the system to fail when it didn't before.
--BillJamison
----
Compare the case where the program has extensive tests that are run every time anything is released, and where it doesn't. Is the probability that ItWasSomethingYouJustDid different in these two cases?  --RonJeffries

This occurred to me as well, and I began to comment on it.  I decided the scope of the problem hadn't been restricted to something that would necessarily be detected by unit tests.  How often do y'all run functional tests, Ron? --BillJamison

We like the unit tests to go FAST because we run them at our desks before going to the integration machine to release. We also run a large selected subset of the functionals, at the integration machine, each time we release code to the config - because we found that they found problems that otherwise required debugging later. We run them again before we push the code to the production GemStone system.  If we were as good as we say we are, we would beef up the unit tests so that they detected more of the stuff the functionals find, but we wouldn't gain that much speed in release so we haven't gotten around to it. --rj