When the developer tools fail

As developers, we pride ourselves on our analytical skills and being able to quickly deduce a problem.  Being “engineers” and “craftsmen” we use tools to gain insight and learn about a problem while we determine our diagnosis.  Every now and then, the tools fail.  This evening I was dabbling with some licensing code in one of our dependent .dlls to troubleshoot a problem that one of UK customers is having.  We had our suspicions that the problem is a globalization issue with dates when not running on en-US.

Members of our team know that I frequently brag about avoiding the debugger – this seems to be a rite of passage amongst Test Driven Development developers who seldom require a debugger since they take such rapid but incremental steps when working.  When I am completely puzzled and need to figure out the logic in some code, my first steps are usually:

• Write a few more tests to demonstrate the problem/requirement
• Refactor the code to a form that I can understand (see scratch refactoring)
• Make some reasonable guesses and add some Console.Outs (getting desperate at this point)
• Finally, crumble and add some breakpoints

It was tough to follow this pattern tonight since much of the code is sealed (it is licensing code after all!) and not very amenable to testing internals.  So I started on refactoring the key elements and putting in some strategic Console.Outs based on my assumptions – BUT THEY DIDN’T OUTPUT.  This had me further puzzled so I added some breakpoints and next I saw that it just doesn’t seem to be executing the correct code.  See this…

It is breaking on the “return false” even though an exception is being throw on the line before (plus it never actually hit the earlier breakpoint!).

After deleting .dlls, whacking bin/obj folders, restarting VS.NET, looking for old rogue devenv processes and finally rebooting the box – I am a little more than stumped.  For those interested, I am using Visual Studio .NET 2003 (yes, we still do lots of work in 2003) and with Resharper 2.0 (#259) as my debugging entry point.  I am going to revisit the problem with Kevin tomorrow with fresh eyes (he already confirmed our suspicions about the globalization/datetime issue) and I will report the results from this craziness if they are interesting.

I found this exercising very interesting as it really highlighted how dependent we are on our tools – even though I more or less knew the issue, I was powerless to successfully fix it without my tools cooperating.

Jonathan Cogley is the CEO and founder of Thycotic Software, a .NET consulting company and ISV in Washington DC.  Thycotic Secret Server is a secure web-based solution to both "Where is the password for this router?" and "Who has the password for our domain hosting?".  Secret Server is the leader in secret management and sharing within companies and teams.