PaulFeyerabend says "AnythingGoes" in an epistemological context.
The practice that's derisively known as "shotgun debugging" is often mocked or raged against but it has on some occasions saved the day for me, and I didn't understand the real bugs until days later, if ever.
On other times it has cost people I know, who used it unwisely, a lot of time. Use with care.
Shotgun Debugging is like this: "Hmm, what does this function do? I can look it up, or I can change it. Let's try changing it first. Oh! It worked!"
It is hated.
''This practice has been known as "Easter egging" by technicians for as long back as I can recall. "Gee, is it this? No, look elsewhere. Is it this? Hey! I found the EasterEgg!"
Old Joke:
Q: How can you recognize a field service engineer with a flat tire? A: He's changing one tire at a time to see which one is flat. Q: How can you recognize a field service engineer who is out of gas? A: He's changing one tire at a time to see which one is flat.
Ideally, I like to debug by writing tests. However, what can we do if we don't know where to start? Sometimes ShotgunDebugging can be a great way to begin to understand a problem. As we make changes and observe the effects, we gain some understanding of the poor code. This then gives us some ideas about what some good tests to write might be. Sure, we want to get this code under control so we don't need this crazy approach, but don't throw ShotgunDebugging out of your toolbox. Toolboxes should have DuctTape and staples as well as real fasteners. --EricHerman
When the shot is dense enough, and/or the shotgun is being used as a substitute for cluefulness, you get Tabloid Journalism Debugging: keep flinging mud until some of it sticks.
See also UnitTestingLegacyCode