Debugging, reviewing, and diagnosing software defects or code is at best a daunting task. Sometimes the simplest change to an environment, code file or build machine can cause hours or days of frustration. Software developers not only have to write code, but also need to be forensics experts.
This post is inspired by the first line of this song by Tracy Chapman, “There is Fiction in the Space Between”. We were fighting a build system configuration issue for several hours. At the end of the day, it turned out there were parameter differences in “AnyCPU” and “Any CPU”. What is interesting is that these parameters were generated by default for us initially from two different systems.
On top of this, the system was presenting some false positives to say that the build succeeded. The head scratching moments were plenty. Eventually, the problem was caught by a second pair of eyes looking at diagnostic level log files.
Don’t Read Between The Lines
While one could point out that anomalies happen in development and coding environments, the results are pretty predictable and repeatable. I see many developers struggle with debugging, especially when they have “certified” it works on their machine. If your program has detailed logs or diagnostics, use them.
Try to isolate the area where the call is failing. Usually understanding the source code logging messages will be a big help. One of the things that I would suggest doing is to add additional diagnostics to the code if you can, so the next person may have an easier time if an error arises.
Four Eyes are Really Better Than Two
Don’t bang your head against the desk for hours pouring over the same problem. Bring in the second or even third set of eyes. It is not only the eyes, but the insight other developers may have with the problem at hand. Don’t be intimidated by the “Oh duh” moment that usually happens, we all have them.
Diff Tools Really Make a Difference
Comparing what changed is critical in software development. I find an increasing number of developers have never used diff tools or don’t use them effectively. Make sure it is in your toolbox.
Any developer who hasn’t worked on an issue where it has taken hours or days to fix probably hasn’t been in the software industry long. This is one reason why estimates can get out of whack quickly and fixes are never as fast as people want them to be.
What is the hardest debugging scenario you ran into with the easiest fix?