Hairloss treatment for developers

A technique I’ve found quite useful is the Fishbone diagram. Actually it’s not the diagram that’s useful – it’s just that it forces me to Stop, Think then Act. Many bugs get sorted via the debugger or just plain old desk-checking but some problems are much more perplexing. You know, like when your FormatAllLocalHardDrives routine never seems to be called by your XML-based UI. Or when your app just can’t figure out where that ODBC DSN is.

So the fishbone should come out when it’s past your bed-time and you are still trying to solve the same problem that you started at lunch. Crank fishbones out when your hairloss is due it being torn out and not your spritely age. Use them when you feel as dippy as a doughnut for not solving the problem.

Stop – The end of Quick and Dirty debugging
Of course, the first problem is realising when it’s time to stop and think. Steve McConnell suggests you set a maximum time for this quick and dirty debugging in his book Code Complete. I agree but we all know how time flies when you’re having fun. What could have been a “I’ll stop in 15 minutes” becomes “Holy Potatoes Batman, when did everyone else leave?“. I’m still thinking about this one.

Think then Act
Now you’ve finished your quick and dirty debugging dash, it’s time for a little more cognitive process. Here’s some pointers:

1. Note what you’re trying to achieve. It’s often useful to remember the point of the code in question. Instead of spending the rest of the day debugging this code you wrote in an hour, perhaps there’s a different way of writing it so that this problem isn’t manifested. It may well be better use of your time.
2. List all possible causes for the symptoms. And don’t just skip some because you think “that’ll never be the case” – this is how I ended up writing this post (naw, the log messages aren’t in the file because stderr is redirected somewhere – it’ll never be because my routine isn’t actually called). Be thorough and engage the brain. Writing it down with the old pen and paper is a great aid to this.  Let me repeat that: Writing it down pen and paper will help you.  Yes, it will. So do it!  And I’ll check on you…
3. Make a battle-plan. Prioritise what you’ve written down so you can determine the most-likely to the least-likely causes. Then figure out some tests to see if each cause actually is the cause of the problem.
4. Give battle. Take that sucker bug down! All going well you’ll have found that one of your probable causes was the actual cause. All not going well means that Murphey has found you and you’ve run out of ideas with the bug unfixed. Let’s leave that for another day, shall we?