Simon TathamMay 23

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 threadkætMay 23

@simontatham I wonder if this is related to the "overlapping bug" problem? Sometimes when you come across a hard to understand bug in a (probably legacy) codebase, you spot another bug which is much easier to explain mixed in.

I always advocate fixing that small bug first unless it would turn into a major side-quest. Anything which contributes to the general confusion, even in a small way, is bad for solving the big one.

The goal in finding and fixing most "eh?" bugs is to make it increasingly explicable. (And often the fix is then trivial). And in bad codebases (more common than folk think) there could be maybe two or three "annoyances" which interact in strange ways to hide the underlying problem.

Show threadBai ShenMay 23

@chiffchaff @simontatham 1000 percent this.

I think a lot of the problems come up because devs are scared to touch more than the bare minimum because they might break something else. I once saw someone change a return type but not the method name.

It's also the kinds of things management complains about spending time on, because "it works, why fix it?"

Show threadkæt

@baishen @simontatham It can sometimes be hard to know whether you're hitting Chesterton's Fence or not, especially if code is weak on tests. I used to work on code that was 15+ years old and had 10k+ bugs fixed against it, and it could be really hard to tell if something was a bug or deliberate.

One reason for that was it was modelling science, the world is messy, and much of the code written by non-programmers, so it was very hard to distinguish "coding good-practice they didn't understand" from "science I don't understand".

May 23 at 12:31pmWeb
Show threadBai ShenMay 23

@chiffchaff @simontatham TIL Chesterton's Fence.

I agree that it can be difficult to discern sometimes, but my example and others that spring to mind are far removed from the fence. They're obvious things that should be removed/fixed but no one wants to do it. Reasons vary, but are generally all signs of bad culture/environment.