Debugging

"… when you have eliminated the impossible, whatever remains, however improbable,must be the truth?”

- Sherlock Holmes (Sign Of Four)

The age old theories used by crime detectives are no less applicable to the modern day geeky act of debugging. Debugging starts with suspecting everyone in the premise and gradually eliminating each probable in the list of suspects. All said and done, the actual problem lies in identifying the right premise and short listing the suspect root causes.

All defects fall in two categories, one which is reproducible in all environments and one which is not. In the first case, it is more often than not, related to whatever stays constant between the environments (code) and in the second, invariably towards environment dependent settings (configuration values, software version/patch, hardware specifications, memory, firewall, data, incorrect deployment etc).

Ruling out options without enough evidences is a grave sin in debugging. One may always start with ruling out the simpler to validate probable, which is more methodical and safer to approach. One can also choose to rely on their sixth sense, hunch and experience (ability to relate to past incidents) to pick the validation sequences,which at times prove to be the quickest debugging approach. The flipside is that if your hunch fails, this approach often becomes annoyingly lengthy for a simple defect.

The modern day development environments have state of the art support for integrated debugging tools catering to various debugging needs. (See Visual Studio /Eclipsedocumentations on Debugging Techniques)

One of the important aspects of debugging in production or similar environments with limited access to real-time debugging is to build plenty of instrumentations/logging(See Instrumentation Options in .Net/Logging Application Block/Java Logger API/Log4J)around the code. For ASP.Net applications, one can leverage ASP.Net tracing feature to have a runtime diagnostic ability, which needs to be handled carefully for space constraints.

For runtime diagnostic, one may also resort to an appropriate application/ runtime profiler. (See CLR Profiler, SQL Server Profiler, ANTS memory Profiler). Another interesting tool is .Net Reflector PRO, which lets you seamlessly debug assemblies without source.

Equally important in debugging is having a consensus on whether a defect is repeatable or not and historically this has been the most painful aspect. Of late, we have a number of options where with different Test Suites are addressing this point by providing Test Recorders and easy simulation of the scenario. (See what’s new in VSTS 2010 for Testers, Test Manager Integration with Rational Functional Tester)

Network Traffic Flow can be visualized and monitored through a tool called FlowScan which produces graphical images that provide a continuous, near real-time view of the network border traffic.

Equipped with all the tools and techniques, one still faces challenges in debugging primarily due to jumping into conclusions with inadequate analysis of available information and lack of patience in case of hard to debug/ weird defects.

Self nurturing is very important, as with experience, intuition, diligence and faith,one gets the best debugging tool within one’s self.

Happy Debugging!