As I have said before, debugging is a complex and time consuming process. I have outlined 10 resources for debugging, and provided a primer for things not to do when debugging. Now, we get to the meat and potatoes of debugging. This is a guide of things to do when debugging. I have broken this guide into three sections – a description of the Scientific Method of Debugging, Tips for Hunting for Bugs, and Bug Prevention Methods.

Scientific Method of Debugging

This is a parallel to the Scientific Method that you learned in your grade school science class. The book Code Complete by Steve McDonnell outlines this methodology to debug your applications.

• Stabilize the bug by identifying the simplest test case that reproduces the error
• Locate the source of the bug
  • Gather data about the bug and its behavior
  • Analyze the data regarding the bug
  • Form an hypothesis about the bug
  • Write test cases that would prove or disprove your hypothesis
  • Run the tests and prove your hypothesis, or begin again with a new hypothesis
• Fix the defect
• Test the fix with all of the new unit tests you have written
• Continue to look for similar, cascading, or peripheral errors

For a more detailed breakdown of the Scientific Method of Debugging, read Code Complete by Steve McDonnell.

Bug Hunting Tips

These tips for finding bugs, broken out into different areas, will help you narrow down where your bug is.

General Tips

• Be sure to save the original source code
• Be sure the fix the problem, not the symptom
• Make one change at a time
• Check and Double Check your fix
• Consider the possibility that the bug is generated from multiple sources
• Divide and Conquer
• Check other places where bugs have existed
• Check other places where code has changed recently
• Compile the application again

Logging

• Insert Trace, Print, or Alert Statements to help track the bug
• Create a logging methodology to trace the application
• Check the Log Files of the servers, etc.
• Search the web for the stack trace

Unit Testing

• Design By Contract
• Write unit tests that cause the error
• Try to reproduce the bug in different ways
• Try boundary cases and special cases

More Complex Methods

• Recompile with a different compiler
• Create a mini version of the application
• Sequentialize the Parallel to see if it is a timing or resource issue
• Try the code in different environments (local, dev, test, prod, other developers’ machines, etc.)
• Grab someone else to talk through the bug without looking at the code (explaining the problem may trigger some ideas)
• Do a full, in-depth code review on the broken code

Last Resort

• Rewrite the whole section of code that is causing the bug
• Take a break for a few minutes, or an hour, or until the next day, to give your mind time to process the data

Bug Prevention Methods

These are things that you should be doing during the planning and development of your applications that will help you identify, fix, and test your bugs after you are done with development.

• Identify and track consistent bug types within your own code
• Introduce debugging methodologies early
• Implement loose coupling techniques
• Implement Information Hiding Techniques
• Write a regression test that tests the bug you just fixed

So… these are some different ways to attack debugging. Are there methods that have proven themselves that you have used? Do you take a different, more unique approach to debugging? What have your experiences shown to be your best practices? Please leave your feedback and let me know what you think.

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?

Blogs are not new anymore.  They have been around for a few years, and have proliferated fairly deep into the technology culture.  If people are not writing one of their own, they are reading one, or a handful of them, or have an RSS aggregator where they are reading dozens or hundreds of blogs. 

Blogs have lots of uses.  They are great for viral advertising, news publication, syndication, and collection of public opinion about a topic.  You can have a personal blog to share photos of your vacations, a corporate blog for press releases, a news blog for niche news, and a host of other reasons to have a blog.  Blogs are an easy way for anyone to produce and consume any information about anything from anywhere. 

But blogs have taken off within corporations as well.  That is my interest here.  We have deployed a blogging pilot in the workplace, and I have become a big proponent.  At first it was part of my yearly objectives to help pilot and proliferate the use of blogs.  I have blocked time on my calendar twice a week for a half hour to post to my blog.  Now I am one of the most frequent bloggers in our pilot, and I blog both inside and outside the company.  I do this because I see such a value in the process.  Blogging is such an important tool in my manager arsenal, and I thought I would list the benefits of blogging from my experiences for the team and for the company.

Knowledge Sharing

Blogging inherently is a way to share information with its readers.    The writer composes the message, and it is consumed by many readers in the blogosphere.  These messages are (obviously) either bottom-up or top-down.  Bottom-up messages are written from the perspective of the line workers and low to mid level managers to express ideas or experiences they have had.  Top-down blogs are a way to deliver executive messages, such as strategic direction, corporate status, and announcements.  Blogs act as a written memory of events, lessons learned, experiences, successes, or announcements.  Blogs can also be a way to share expertise on a specific topic, such as data management, service oriented architecture, design patterns, or search engine optimization. 

Idea Solidification

The writer has to take the time to think about the message they want to deliver, collect their thoughts, organize them, and express them clearly.  That way the readers can read a focused message that delivers a clear and understandable message.  Blogs can also be a way to develop, solidify, and evolve an idea by posing a question, idea, or concept, and collect and narrow an idea through constructive comments. 

Project Management

Using a blog to document a project and its progress is a bit unorthodox.  Typically a wiki or another more collaborative environment is more appropriate.  But blogs are so easy to use, they make for a good medium to capture progress and communicate them easily.  Again, they act as a written memory of the project’s progress, successes, and lessons learned.

Cross Team Communication

Blogs are a great way to provide a medium for dynamic networks of conversations across teams.  These teams could be local or distributed, days, nights or weekends, and it will not matter.  A shared blog space will allow for ideas to be spread, information to be distributed, questions to be asked and answers to be shared.  Blogs crisscross people, departments, silos, grade levels, and experiences.

TeamBuilding

The simplest thing that blogs do is to bridge the boundaries of distance and culture by being always on, able to be shared and viewed at any time.  When launching a blog or posting a comment, a person takes themselves in written form and puts a bit of themselves out for everyone to look at, examine, scrutinize, comment on, and critique.  Successful corporate blogging creates an atmosphere of trust, so that people are not threatened, intimidated, or frightened to expose themselves.  Successfully sharing and collaborating this way fosters a spirit of participation that encourages people to continue to contribute their thoughts and ideas.  This leads to team learning and growth across the team, from within the team, and makes them stronger together. 

So what is your perspective on blogging within corporations, or blogging in general?  Is there value?  Is it a waste of time? Leave me feedback and let me know your thoughts.

Resources

• BCOM 522 – Corporate Blog Use: Internal, External and Beyond
• SearchEngineLand – Managing Search Marketing Campaigns With Social Media Tools
• Read/WriteWeb – Internal Corporate Blogging
• Global PR Blog Week – Internal blogs: How to design powerful conversations that open possibilities for action and collaboration within blogs
• Better Business Blogging – Internal Blogs: Benefits and Uses of Team Blogs 
• BlogTronix – Types of corporate blogs – Internal Blogs