How to solve application problems in two steps

by Giuseppe Lanzi on 11/06/2012

When you need to sort out abnormal application behavior, it’s the approach that counts.
First of all, you have to be able to replicate the problem, because as long as it happens unexpectedly, it’s difficult to understand, let alone solve.
Once the problem can be replicated, you need to isolate it, meaning you have to separate the anomaly as much as possible from normal application behaviors. The point of this step is to identify the cause of the error, and it may be the toughest part of the job. You need a precise method.

I’m telling you this because I’ve noticed that in many support requests, this task hasn’t been done, or hasn’t been completed. It’s often the case that once you finish this task, you can find the solution on your own.

To get it done right, I follow a very precise method that can be summed up in two steps: divide and choose.

The first thing to do is divide the elements in question into two distinct parts, to be analyzed working more from what you observe than from what you already know. You can’t take anything for granted; everything must be under scrutiny. If, for example, you need to understand why a report element is not formatted as expected when printing, the parts in question might be the query and the formatting events.

The second step is to choose which of the two sets to discard, and which to investigate further. For this, you need to design a test to find out if it’s the query that isn’t returning the data in the expected form, or if there are formatting events that are not considering a particular case correctly. The results of this test will allow you to narrow your focus on the problem. If the problem crops up, we can repeat this method, focusing only on the area that contains it. If neither area causes problems, then we need to reapply the method choosing a different set of elements.

This might seem like an obvious approach, but often circumstances lead us to tackle problems without this kind of rigor. So we find ourselves looking at the entire application, hoping for some unlikely intuition on the nature of the error while reading an endless debug.

If you don’t already have your own error-detection method, I suggest you try this one.
It always works for us.

Leave a Comment

Previous post:

Next post: