Diagnostics
These days, due to my internship at Autodesk, my on-site availability is quite limited. The bad part is that after a deployment, quite a few questions come up and some minor corrections have to be made. Giving instructions over email to non-technical staff isn’t quite that easy, but it was easier than going on site. Of course, the problems came back and those procedures I was nearly 100% certain of didn’t work.
After going on-site today, I realized that the fixes were in fact correct. My failure was to provide steps to diagnose wether the fix worked or not. In order to process data properly, the system had to be placed in a state where some data had to be processed. Without this crucial step, there was simply no output.
Of course, I did have some real issues to fix and training to provide, but I did learn something today.
On a different kind of diagnostic, when analyzing a large code base and trying to find the location of branching between two behaviours is a lot easier by performing a diff on the backtrace than by walking in an interactive debugger. This is especially true if the diff tool can highlight differences within a line and not only the entire line. This way, you can see the changes in parameters passed to functions. I actually got the idea after reading Beautiful debugging in Beautiful Code. In the article, they use divide and conquer algorithms on the program states or change sets to identify bugs. That was a little too hard to set up and I wasn’t really looking for a bug, but it’s the kind of article that reminds you that tools can be combined in different ways.