The Lost Art of Debugging – Part 2 – Things Not To Do

Debugging is a complex and time consuming process.  In my last post I listed 10 Resources for Debugging, both web sites and books, that every software developer should read to keep their debugging skills sharp.  Knowing what not to do is just as important as knowing what you should do.  Here is a list of things not to do when you are debugging your application

• Don’t guess what the problem is
• Don’t dive into making changes without a plan
• Don’t code right away without a thorough analysis
• Don’t fix the shell of the problem, not the problem itself
• Don’t trust line numbers in compiler messages
• In fact, don’t trust the compiler messages at all
• Don’t ignore the value of automated unit testing
• Don’t delete the original code
• Don’t ignore recent changes to your application
• Don’t ignore resources available to you, like the Internet or the Library

This post is a teaser for the one that is to come – what thins should I do when debugging?  Is there a more formal process for debugging?  What steps should I follow?  What things should I look for?  What place should I look?