You need to be able to measure your tests, even if the measure is as corse as "it worked" versus "it didn't". To be able to do this, you need to know what changed and what you expect, so you need to change a controlled number of things and you need to expect something.
This is best understood by taking the typical case of the crap debugger, where they try a bunch of stuff, notice that things changed and read into the things they noticed any-old-crap and work from there.
Suppose some bug is causing the financial reports to add up wrongly. The crap debugger starts by changing a few things and seeing if anything changes, when something does s/he looks at what changed and what happened. Which of the 10 things we changed caused the change?
Who the hell knows.
In the worst case, the debugger (and often the wider team) will talk themselves into believing one of the causes, spending hours talking about how that must be the cause instead of actually working through a proof.
The problem is that you cannot assume that a change you made has had no effect. Undo the change if it either didn't do what you expected or didn't do anything at all.
I.e. prescribe for 1 condition at a time. When that diagnosis proves to be false, undo
But it's 4am. We already tried 10 things at once. Now what?
Oh, well, you've really screwed that up, haven't you? You didn't follow the rule and now it'll never, ever, ever be fixed.Except you know what changed and that's quite useful. If you can list what you changed, and what the effect was you can cross-reference these and find the probable cause using differential diagnosis.
When pushed for time, it's completely normal for people to change loads of things without reverting each change, but you have to be ready to work out where the new behaviour came from. Which change caused the change in behaviour?
The "brass bar" story is nice [from the green debugging book]. Engineers on nuclear submarines are trained to avoid trying out 20 things when something goes wrong. Instead they grab hold of a brass bar and read all the dials.
They read stuff. They don't try anything until they've done a lot of reading.
When you're fixing, do the same between tests and trails. Don't do anything until you've read all the dials, logs and test results and you know what the system is really doing.
