I don’t know the history of the term red herring, but to me it means something you’re looking at thinking it’s the problem, when it’s just not the right problem.
I have to return to the red-herring in my recent MEF debugging post. I wasted a lot of calendar time thinking the problem was in MEF. It wasn’t. It was in my code.
The biggest hurdle to effective debugging, the biggest time waster, the mind killer of debugging is the red herring. When you are debugging the quickest way to become ineffective is to latch on to a perceived solution and cease to look in other directions. Nancy Folsom and I wrote about this years ago as I was adopting her style of debugging. Her answer is very simple – debug using a scientific method which means you attempt to prove yourself wrong. When you think a problem is in a particular location, figure out a test that will tell you that you are wrong, and do not cling to the incorrect assumption that the converse is true.
There are few tests that can prove you are correct because there are many reasons for a particular result. If you look back at my previous blog post, there’s a profound example of this. While I didn’t perceive it that way, my test of the dictionary was actually evidence of an inheritance problem, but in the attribute while I thought the inheritance problem was in the interface. But remember it wasn’t an inheritance problem at all. Had I taken this as “strong indication” (similar but not quite as strong as the word “proof”) that my theory was correct, I would have continued to dance with the red herring and not proceed toward the solution.
Debugging is full of red herrings. If you watch your debugging process you’ll find you make dozens of incorrect guesses about the problem. This is good. You don’t know what the problem is and you must creatively come up with dozens of ideas. The trick to effective debugging is to come up with these ideas, phrase them as questions that can be answered, prioritize them based on likelihood and ease of testing, and then run tests that prove each idea wrong so the wrong ideas can be discarded as quickly as possible.
Team this with “Price is Right” techniques. There was a game on that show where someone had a short amount of time to guess the right price and an answer of high or low. The smart player guessed any number, then split the difference between that and a boundary condition. This can also be called divide and conquer debugging. While the scenarios where divide and conquer is effective is limited, it’s a valuable way of thinking/debugging in those scenarios. For example, if you have the wrong value displayed, is the database returning the right value, does the object contain the right value, etc. It’s a subset of scientific method debugging, but it’s a significantly important subset to call out.
Enjoy your debugging! It’s where you spend most of your time.