Debugging Tips

The following are some soft tips, some more obvious than others, but you might find one or more useful, so I'll list them here:

• If you have a bug you just cannot track down, walk away from the problem and return to it later or the next morning.

• Always try to reproduce the problem. For example, I often request that my customers provide a snapshot of the data they are using in a test environment so I can re-create it in the development environment. This snapshot can easily be obtained using database tools that allow you to import/export data (Aqua Data Studio is one such tool; aquafold.com). Also, ask the customer to re-create the problem for youthat is, what action was taken and what state was the application in when the problem occurred.

• Get a second pair of eyes to look at your problem. There is nothing like having someone walk up to you and tell you the problem within a second because of bringing a fresh perspective, whereas you might be heads down and too close to the problem (the can't-see-the-forest-for-the-trees syndrome). If you are using Extreme Programming, this is one of the side benefits you get from pair programming (details at extremeprogramming.org).

• Use a process-of-elimination technique. That is, in your mind, separate the code that works and the part that doesn't. If possible, physically separate the code that works from the code that does not. Debugging smaller snippets of code is much easier than a complex system.

• Determine whether any of your dependencies are causing the problems. For example, has an external API or interface changed? Is the data bad? Has the application server or database version changed? Is it a hardware problem?

• Program defensively by checking for valid input values. A nice way to do this is by using assertions introduced in J2SE 1.4 (details available at java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html). Another option is to check for valid values manually and throw a java.lang. IllegalArgumentException exception for invalid values.

• Use new Exception().printStackTrace() in your code to print the stack without actually throwing an exception. This can be helpful if you want to know where something came from.

• Try to always write simple toString() methods in your classes. This can help significantly when you are printing objects.

Personal Opinion: Bug Prevention Techniques

Bugs are a normal part of our lives as software developers. Here are a couple of suggestions to help you prevent bugs.

For starters, there is no substitute for printing out your own code and walking through it on paper, away from the computer. This is perhaps one of most effective practices, but requires a bit of patience. Many organizations take this one step further by doing code walkthroughs. Extreme Programming handles this via its pair programming.

Another good option is to walk through your code using a GUI debugger. You don't have to use a debugger just for debugging; you can also use it to verify that your code is working as you expect it to.

However, in my opinion, one of the best ways to reduce bugs is by developing software in smaller chunks. In other words, for each iteration, two weeks in length, we have minimal requirements up front in the form of high-level and low-level requirements. For the high-level requirements, you could do some initial UI sketches (for a user interface application), domain modeling, user stories, and so on. These are typically done at the beginning of a release. At the beginning of each iteration, you get detailed requirements in the form of acceptance tests. Given this approach, there is a lot less that can go wrong. Furthermore, when you factor in the test-first approach (recall the "Writing Unit Test and Actual Code in Same Sitting" sidebar from Chapter 7, "The Spring Web MVC Framework") combined with refactoring as and when needed, your code is bound to be more solid at the end.

Iterative development using short and fixed cycles (two fixed-week iterations, for example) combined with active stakeholder participation can help reduce some of the pressures of time-sensitive software delivery; this is possible because the customer sees progress on a regular basis and is likely to be more flexible and understanding when it comes time for missed deliverables. This reduction of time-sensitive pressure can also help you write more stable code and not just something you throw over the wall, so to speak.

Finding bugs is no fun. I sometimes feel like it is similar to looking for a real-life tiny bug that is hiding in a big room filled with lots of stuff.

By doing true iterative development (from requirements through deployment) and having smaller-size fixed-iteration lengths (two weeks being ideal), you are likely to prevent bugs and enjoy coding a lot more!