Debugging nightmares: Common software debugging mistakes keeping you up at night?

debugging software

If you are a software developer, long nights filled with infinite coffee, heavy eyes, and hair pulling is not a foreign concept. Every time you think you’re ready to turn off the lights and shut down the project, you find another software bug creep out to taunt you. It looks familiar, like you’ve seen it scurrying on the floor in previous nights, but you can’t quite remember how you got rid of it last time.

Sound about right?

Most software bugs fall into three broad categories: The first is straightforward and repeatable. Due to its nature, it is the easiest to find and to fix. The next one plays catch-me-if-you-can, and hides when you try to trap it. For example, every developer has tried to debug a problem by putting in “just a couple of ‘print’ statements”, and amazingly the code starts working. Then, a few more ‘print’ statements are added and the problem re-emerges but dressed in totally different symptoms. The final software bug is the monster that haunts our nightmares, the one of such complexity and obscurity that it appears to be truly random and not following any discernable pattern. It might only happen once a week after running mode A and then mode B for a thousand times in a complex sequence, under a full moon, when you go to get a drink and a cold piece of pizza. This is not only true in high performance embedded computing, but also in any type of software debugging. All these software bugs create problems, whether they end in dismal failure, incorrect results, a hard crash, or the program lost in the weeds.


Software bugs





When you look back at the different types of software bugs that have haunted your late nights, how many of these sleepless sessions could have been avoided? How many of these software bugs could have been resolved more easily?

1. Did you even check if this is a problem you’ve solved before?

When software debugging, bursts of creativity and intuition must work in harmony with rational problem-solving skills and the best available debugging software tools for the job. Often developers get so caught up in the problem at hand, they forget to step back and think: “Where have I seen this before?. Have I solved a similar software bug that could lend some insights for this?”. Instead, it is easy to trap yourself in a whirlwind of trial and error on a quest to come out on top.