by (( Nikki ))

Created on: October 29, 2009

"Any given program, when running, needs debugging. Any debugged program is obsolete." - Murphy's Law variant

You never really learn to swear until you learn to code. Profanity is the one language all programmers know. I'd say bugs are the #1 cause of most creative language outbursts. More specifically, trying to find and fix the bug. The process can be tedious, time-consuming, and headache inducing. Some bugs can't even be replicated without researching what the user did before they encountered it. If you can't find it, you sure can't fix it!

Here are some tips to help you find the elusive bugs in your code.

1 - Get a full description of the bug

Some bugs have simple descriptions and are easily replicated when you test. Others are more elusive, only appearing after a user does a specific series of actions in a specific environment.

Make sure you truly know what the bug is before you try to find and fix it. Have the user include screen captures, or have a help desk technician shadow the user's session if possible.

For examples of workable bug descriptions, check out public bug databases, such as the one for Mozilla. Consider implementing a good bug tracking system for your application and have users submit bugs in a clear and concise manner.

2 - Drop the assumptions

"The code that is hardest to debug is the code that you know cannot possibly be wrong."

Don't assume. If you find yourself overlooking a portion of code because it "always worked before", that's a red flag. Don't assume anything; use a debugger, assertions, console write statements, print statements, or whatever your language and platform allow to be 100% certain of the value of variables, how many times a loop is executing, configuration setting values, and method call order.

Don't waste time debugging when the issue was actually caused by a combination of factors that had little to do with your code (other than data validation that you should have done, but didn't).
Don't assume that when your application was deployed, every instruction was followed.
Don't assume users are reading help sections or following onscreen instructions.
Don't assume network connections or files are always accessible.

3 - Use your IDE

If you can replicate the error in your environment, make use of it. Breakpoints and watches are your friends. Make sure nothing is changing the value of a variable and that the state of the application is what you expect it to be. Some frameworks support breaking out into the debugger when a

• 1
• 2
• Next Page >>