I have a couple of posts lined up in addition to this, but while doing some blog maintenance I discovered that this post will be my100th post, so it seemed appropriate to pick the post that “100” in the title.
I had a few supportive comments on the predecessor to this post and wanted to follow up with some additional thoughts I had on the basics of debugging. I was thinking about how to describe debugging when I flipped on the television and CSI was on (not really a coincident since CSI is always on). I thought – “that’s debugging!”. They use different tools to learn different things, pay attention to all clues, and take the time to prove or disprove them while working through a series of hypothesis. That’s exactly what debugging is. I was still preparing the debugging material for the course I was putting together, and thought it would be cool to grab some sort of detective graphic. While poking around, I discovered the CSI site on cbs.com. Then I noticed the CSI handbook on the same site. There is a list with dozens of tools, and dozens of procedures. Now, I’m not a detective, so I can’t say for sure, but from what I know about testing and debugging, and from what I can read on a television show web site, I would say that testing and debugging are exactly the same thing (without, of course, the dead bodies).
Another thought I had for people new to debugging is to do everything possible to avoid it. I don’t mean skip it – I mean write solid maintainable code that needs as little debugging as possible. Unit tests, assertions, comments, code review, etc. all lead toward code that has a better chance of being rock solid in the first place. Debugging is a last resort when you made a mistake, and should be avoided.
Mark Waite mentioned the Agars book in a comment, and I wanted to give it my two thumbs up seal of approval. I reference it often, and it’s been influential in my thoughts in this area. It’s a great read for all levels of people who want to be better debuggers.