Simon Tatham1d ago

Two different approaches to debugging a software problem:

The Sudoku approach: stare at the limited set of clues you have, and think harder and harder about them until you find a way to deduce something useful.

The Minesweeper approach: don't even try to figure out the solution from only the clues you have right now. Instead, focus on finding a way to acquire another clue, and then using that to get another, and so on. Eventually you've collected so many clues that the answer is obvious.

Sometimes the Sudoku approach is necessary, because you've got all the clues you're ever going to get. But I think my new motto is "Never Sudoku a problem when you can Minesweeper it."

Show threadandre1d ago
@simontatham This sounds interesting. I'd like to see examples of both.
Show threadSimon Tatham1d ago

@a32 my type example is where you first become aware of a bug because some kind of automated test run fails, and presents you with a log file containing a cryptic error message.

The Sudoku approach to this involves trying to figure out what the error message might mean, e.g. by grepping the source code for the message string and backtracking from there to see where the failing function might have been called from. Sometimes there's more than one possibility: a characteristic of the Sudoku approach is that you try to _guess_ which one seems more likely in this case.

The Minesweeper approach starts by reproducing the same failure on your own machine; stripping off all the layers of test-runner script and makefile until you have a single shell command that runs the actual process that crashes; then running that command again and again in ways that give you more information, such as
• in a debugger
• under strace
• with extra verbose or diagnostic options
• with modified versions of the input file that provoked the failure

A Minesweeper-oriented developer wouldn't bother trying to _guess_ which part of the program had called the failing function. They'd put a breakpoint on it, and get the debugger to _tell_ them.

Show threadaspragg
@simontatham @a32 Now I'm trying to figure out which of the two approaches the tactic of "make educated guesses about the best place to put a bunch of `printf()`s and try again" falls into 😆
May 23 at 5:59pmWeb
Show threadi.grok18h ago

@aspragg minesweeper

You're gathering more clues

Show threadAlexander The 1st14h ago
@aspragg @simontatham @a32 I mean, that's still Minesweeper-y to an extent; even if the printfs don't actually trip when you reproduce the bug, that tells you more information - namely, that the bug is *not* where you guessed where it was.