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

Answer 1

Using your version control system, go back in time until just before the bug appeared and diff that code against the first revision where the bug is introduced.

Use a binary search tree approach to make the process faster.

I'm told there's a git command or tool that makes this easy.

Answer 2

• Use the debugger, make sure you know what the 'expected' behaviour is, find the point where 'expected' behaviour is no longer happening
• A source control helps, in case when you can roll back to the working version of the code and start adding your changes back little by little, until you find that bit that breaks the functionality.
• Use the event log. I had a bug recently which logged a DllNotFound exception in the Application event log. That made no sence since the file was there all right. It took me some time to peek into the System log, and there was another error there about a dependency missing. So use all available logs. Write critical information to the event log yourself and make sure it appear as expected.
• Use google or stackoverflow to search. Most problems have been experienced by other people before, you might be surprised by how many people had the same problem.
• START writing a question to stackoverflow. For every question I asked there were at least one or maybe two that I did not, because just formulating the problem properly in writing led me to the solution
• If possible, create a small 'throwaway' empty project and try to replicate the problem there. That might help to find out if the problem is caused by your code or by other parts of the project
• Use the help of a colleague
• Walk away for a while if you can, or at least try to do something different. Your mind will keep working on the problem subconsciously, and may deliver a solution soon.
• If nothing helps, read the documentation and manuals. ( :-) )

An example where nothing helped: Once I was going crasy because my DataGridView would not show checkboxes in a checkbox column. There was absolutely no way it could be possible. Took me long time to find out that, for some reason, the checkboxes would not show if a column was less then certain width. They were still visible in the designer. (I think the reason was a certain UI toolkit we were using). I wouldn't find out, but just by accidental mouse move I resized a column at run time and voila - there they were, my checkboxes, all this time, sitting there invisible.

Answer 3

Use an editor that lets you set breakpoints

With Breakpoints, you don't have to start at the beginning of the code over and over as you debug, which makes it easier to step through the code

Answer 4

I agree with sleske but one thing I'd add is to break the unit of work into smaller units. So if it's bug in a method...make smaller methods. It will clear the fog of war.

Answer 5

If your .Net project fails on Mono, debugging is a nightmare. Most of the time it's about Console.WriteLine.

There're a few options. You may:

• Debug on a linux machine. There's a command-line debugger for mono.
• Run the code in a linux machine, and remote-debug from visual studio using some remote debugging plugins (I didn't succeed at it yet)
• On windows, run MS .Net runtime but link it with mono class libraries. You can do it except for mscorelib, though it involves some messing around with the .net framework settings like disabling strong key checking for .net assemblies.

Answer 6

Know the value of what you're trying to fix. Don't waste time on "fluff". Document, work around and move on if value less than cost.

If value>cost, and you've had a good crack at it, then communicate it. Many times a tough problem is only a tough problem due to the perspective of the person involved. To others, things can often be highly obvious. Don't use your team as a crutch, and definitely respect their time etc but by the same token realize and tap the value of having workmates and peers.