Programming - Liberating The Bug

It's inevitable for programmers to run into a programming bug that is difficult to pin down. The most difficult are:

⁃ Time or Timing related: the bug only shows up at certain times, or based on other time-related events

⁃ Secondary or Tertiary: The bug only shows up when one or a series of other events occur

⁃ Hardware related: the bug only shows up when a hardware event occurs, such as an I2C event

I've seen programmers get lost trying to cause and track-down these kinds of bugs. In fact I managed a project that ran 2 months late because the programmer had a tertiary bug that he chased without telling anyone. OUCH!

There are tactics that can help deal with difficult bugs. I've used these to solve gnarly problems.

⁃ Isolate the problem code: separate the problem code out into a test program. This removes working code from debugging sessions.

⁃ Isolate hardware: When chasing a hardware related bug, remove extraneous hardware from the debugging environment. You don't need to be tracking serial port interrupts when fixing a video refresh bug.

⁃ Look for alternatives: after chasing a bug for a day or two, it's worth looking at coding alternatives. Can the problem code be rewritten taking a different tack? I recently had an RSS decode bug that I resolved by rewriting the code to look for a different header tag. Don't fight the dragon for too long.

Fighting bugs is part of the art of programming. How you deal with pesky bugs determines your ability to finish projects on time, or wallowing in lateness.