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?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s