6 Steps to Debugging Code

So you are relatively new to software development and you are presented with one of the most difficult bugs to resolve. What do you do? Where do you begin to look?

In my experience, when this occurs less seasoned developers will do one of the following:

  1. immediately give you a possible source of the problem
  2. immediately write more code to attempt to identity the problem
  3. Agree to have a solution by the end of the week and make NO progress.

Why is this?

One thing I always remind my colleagues is that software development is a science, even though there are some who feel this is an art. Let me repeat this, software development is a science. So, in the field of science, how do we solve problems? Do you remember the “scientific method”? Developers should utilize the scientific method to solve software problems. The 6 steps of the scientific method can be utilized to ease the pain of debugging and increase your likelihood of success.

1. Ask a question

When presented with a bug you MUST ask questions to get a clear understanding of the problem. Within this phase you want to understand all aspects of the problem. In most cases, problems that exist in software are not random. Therefore your goal in this phase of the problem solving process is to remove the random nature of the problem and find the predictable nature of it. Below are few key questions that will assist you in your findings:

  1. When does it occur?
  2. What behavior are you experiencing?
  3. Can you consistently reproduce the error?
  4. Can you recreate this issue in a different environment?

2. Do background research

Take each answer to the questions asked and analyze or verify the information given. Be sure to evaluate the environment or any other specifics that will allow you to make better assumptions. This information should be used to assist you in formulating your hypothesis.

3. Create a Hypothesis

Your hypothesis is what you think the root problem is based on your understanding. At this point, you should fully understand the problem and make an educated guess to where the source of your problem may originate from. This can only be done by leveraging your research to read through the code and better understanding what is being executed.

4. Test your Hypothesis

At this point you will understand all the details of this problem. Take your hypothesis and find the areas within your code that support you hypothesis and begin to put breakpoints in the appropriate places in code. By running the code within the debugger you can view the execution of the code and inspect variable values as well as the execution paths.

5. Analyze your Test Results

Based on the results of your test and debug sessions, review the information that was gathered and the execution path of your test. Determine if your test cases are valid.

6. Accept or Reject your Hypothesis (Draw your Conclusion)

At this point you should fully understand the problem and should be able to accept or reject your root cause hypothesis. If your hypothesis has been proven, begin formulating a plan to fix the bug. If you hypothesis is rejected, start over at step 1 until you are able to find the root cause of your bug.

Advertisements

Understanding the Basics of Windows Azure Service Bus

As we become more distributed in our everyday lives, we must change our approach and view of how we build software.  Distributed environments call for distributed software solutions.  According to Wikipedia, a distributed system is a software system in which components located on networked computers communicate and coordinate their actions by passing messages.  The most important part of a distributed system is the ability to pass a unified set of messages.  Windows Azure Service Bus allows developers to take advantage of a highly responsive and scalable message communication infrastructure through the use of their Relayed Messaging or Brokered Messaging solutions.

Relay Messaging

Relay Messaging provides the most basic messaging requirements for a distributed software solution.  This includes the following:

  • Traditional one-way Messaging
  • Request/Response Messaging
  • Peer to Peer Messaging
  • Event Distribution Messaging

These capabilities allow developers to easily expose a secured service that resides on a private network to external clients without the need of making changes to your Firewall or corporate network infrastructure.

Relay Messaging does not come without limitations.  One of the greatest disadvantages of relay messaging is that it requires both the Producer (sender) and Consumer (receiver) to be online.  If the receiver is down and unable to respond to a message, the sender will receive an exception and the message will not be able to process.  Relay messaging not only creates a dependency on the receiver due to its remoting nature, this behavior also makes all responses subject to network latency.  Relay Messaging is not suitable for HTTP-style communication therefore not recommended for occasionally connected clients.

Brokered Messaging

Unlike Relay Messaging, Brokered Messaging allows asynchronous decoupled communication between the Producer and Consumer.   The main components of the brokered messaging infrastructure that allows for asynchronous messaging are Queues, Topics, and Subscriptions.

Queues

Service bus queues provides the standard queuing theory of FIFO (First In First Out).  Queues bring a durable and scalable messaging solution that creates a system that is resilient to failures.  When messages are added to the queue, they remain there until some single agent has processed the message.  Queues allow overloaded Consumers to be scaled out and continue to process at their own pace.

Topics and Subscriptions

In contrast to queues, Topics and Subscriptions permit one-to-many communication which enables support for the publish/subscribe pattern.  This mechanism of messaging also allows Consumers to choose to receive discrete messages that they are interested in.

Common Use Cases

When should you consider using Windows Azure Service Bus?  What problems could Service Bus solve?  There are countless scenarios where you may find benefits in your application having the ability to communicate with other application or processes.  A few example may include an inventory transfer system or a factory monitoring system.

Inventory Transfer

In an effort to offer exceptional customer service, most retailers will allow their customers to have merchandise transferred to a store that is more conveniently located to their customers.  Therefore, the store that has the merchandise must communicate to the store that will be receiving the product of this transaction.  This includes information such as logistical information, customer information, and inventory information.  To solve this problem using Windows Azure Service Bus, the retailer would setup relay messaging service for all retail locations that could receive a message describing the inventory transfer transaction.  When the receiving store gets this notification they will use this information to allow the store to track the item and update their inventory.

Factory Monitoring

Windows Azure Service Bus could also be used to enable factory monitoring. Typically machines within a factory are constantly monitored to insure system health and safety. Accurate monitoring of these systems is a cost saver in the manufacturing industry because it allows factory workers to take a more proactive response to potential problems. By taking advantage of Brokered Messaging, the factory robots and machines can broadcast various KPI (Key Performance Indicator) data to the server to allow subscribed agents such as a monitoring software to respond to the broadcasted messages.

Summary

In summary, Windows Azure Service Bus offers a highly responsive and scalable solution for distributed systems.  For basic request/response or one-way messaging such as transferring inventory within a group of retail stores, Relay Messaging will meet most system requirements.  If your requirements call for a more flexible system that will support asynchrony and multiple message consumers, it is better to take advantage of the Queues and Topics that are made available in Brokered Messaging.