What Are Some of the Worst Debugging Nightmares?
Debugging projects the traditional way can be a nightmare. Some worse than others. Some that feel like the sort of nightmares where you can’t escape; that can be a typical Wednesday, for an unlucky developer.
Writing code takes time, patience and skill. And yet, even the most experienced, well-rested developers make mistakes. Bugs happen. Other times, these mistakes happen through laziness, forcing other developers and testers to take time trying to correct problems that could have been avoided had more care been taken.
Here are a few ways debugging code can be a nightmare for developers.
- A bug occurs only every so often. Chances of it causing problems are low, but not so low that it can be ignored.
- You didn’t write the code, but have to fix it. The person who did either doesn’t work for the company or can’t be reached anymore.
- You’ve found a bug, but are unable to trace the cause of the problem.
- The bug can be traced to a library; one that is reliable 99.9% of the time, making it the last place you would think to look.
- This bug has taken on many worthy adversaries. None, have defeated it; your boss or client expects it resolved to a tight deadline.
- Failure to fix a bug could cost a lot of money, or your job, if a client isn’t happy with the work or reason a program they’ve invested in still isn’t functioning.
- Your code is interacting with another developers code, through a joint project. The other code is full of bugs, incorrect assumptions, broken source files, not enough local references, outdated packages, temp files and unnecessary comments that muddy and confuse the project. None of it is needed, not when sharing work with other developers. Unfortunately, this same lazy approach causes an investment of time that isn’t productive.
As Troy Hunt, a Microsoft Regional Director and MVP said about .NET project interactions: “Temporary, user-specific or generated stuff does not go into source control!”
- Another developer once had the very same issue, only for no solution to appear on online forums and Stack Overflow.
- The bug isn’t apparent. It only occurs in run-time once the program has been operational for a long period of time.
- You are on a tight deadline to fix a bug, are very tired and delving into code or a field where you have no or very little prior experience.
Above illustration is a frame from The Deadly Mantis (1957) movie.Back to list