What are your best practices for bugs that are hard to solve? [closed]

Answer 1

Leaving it alone and calling your colleague to have a fresh look at the problem. Time and again I find this approach solves the problem in 5 minutes, while you could lose the whole day.

Answer 2

All good answers.

For really tough bugs, such as numerical routines that run for a long time and get slightly different answers from what they used to get, there is a laborious method that usually works.

Get one foot on each side of the problem and work toward the center.

Like get an older version of the program that got the right answer, and the newer one that doesn't. Incrementally make changes to either one to bring them closer together, still keeping one on one side of the problem, and the other on the other. Eventually, you find the one change that makes the difference.

Like run an older good version of the program under a debugger, and the newer bad version also under a debugger, at the same time. Single step them side-by-side until they do something different. Then repeat, homing in on the step at which they start to differ.

I've found this working-inward-from-both-sides method is applicable to all kinds of difficult problems, not just software.

Answer 3

Forget the debugger. Waste of time, most of the time.

First, rubber duck it. If that fails, move to plan B.

Plan B: ensure you have good unit tests. Then you can home in on the problem (assuming you can reproduce it) using techniques such as what Kent Beck calls the "Saff squeeze".

Answer 4

Set a time limit on how long at once you will work on the task, e.g. 2 hours. Once this time is reached and you aren't making progress, take a break for 10-15 minutes which can be going for a walk, eating a snack, chatting with people, whatever besides that problem that can help "reset" your mental focus as after a while, it is useless to try to fix things through brute force.

Make sure you have a clear understanding of what the bug is exactly. There have been times where I'd get a bug that said, "This looks ugly. Please fix," and think, "Where is the spec that I'm supposed to make this look like as I don't know how to make this look good?" sort of thinking. This can also come if you've had to go to someone to referee the finger pointing between developers and testers where each is saying, "I am following the spec." That referee could be a manager, of developers, testers, or projects, but I do feel sorry for those that get pulled into these situations.

Answer 5

One thing that helps a lot is to find a good balance between focussing and not obsessing.

• Make sure you can work on the bug without being disturbed
• But also know when to take a break if you cannot concentrate any longer

And yes, there is a point where a good night of sleep is the best you can do.

Finally, discuss the problem with a colleague, often a second pair of eyes and point of view work wonders. Surprisingly, sometimes just explaining the problem already helps, even if the listener does not say anything. This is called Rubber duck debugging.

Answer 6

Find someone else who understands the basic issues and technology (so they don't give you a blank stare) and explain the problem to them. They often don't even need to answer, just organizing your thoughts enough to explain the problem to someone else often brings the solution into focus.

EDIT: I was referring to Rubber Ducking even though I couldn't put a name to it. Thank you Morendil.