Strides Interactive

Key to effective debuggingFiled Under: Weekly Tuesday Dose of goodness

Hi all,

Most people out there make use of tools to aid them in debugging their source codes. They navigate bravely through the endless waves of methods and function calls till they derive at the point of error.

Most of the time, these people will manage to sort out their problem eventually. However at the same time, causing regression errors to other parts of their application as well.

Most of these people will eventually get burned out by the amount of traversals they have to perform in their jobs. It feels exactly like an endless blackhole.

So what’s the key to effective debugging?

1) Technical knowledge?
2) Domain knowledge?
3) Language knowledge?
4) Debugging tools?
5) Analysis tools?

Let’s find out.

Actually, of all the possible answers above, only Domain knowledge is the closest to the right answer. Even so, domain knowledge itself is not enough make debugging effective.

Of course, we must acknowledge the need of having a good language and technical background in order to spot technica errors.

However, debugging is not just a technical issue. It’s also a design issue.

Therefore domain knowledge do play a part in debugging.

However so, even with domain knowledge, there’s still a need for a bigger picture. That is - the problem tree. Some people prefer to call it mind-map, but I prefer to call it a tree since all branches lead to the root.

We need to therefore split debugging into 2 views:

1) Design view
2) Technical view

Nowadays, technical reviews, static analysis tools and unit test case generation tools help ease the tasks required for the technical view to narrow down the technical analysis.

However, most people do not really care about the Design view of things. At least not in this part of the world.

In Asia, software quality is still in its infancy. Remember once I mentioned about people seeking out memory leaks without seeking the subtle memory leaks due to poor software design?

In my 10 years of software development, when I encounter a serious bug,  (ie, crashes and multiple regression errors), I’d usually have to refer to my design specifications in order to get an idea of what the hell I was trying to do in there.

Then I’ll use my design specifications as a top-down view map while I navigate them through my codes.

Doing so allows me to validate my implementations against my designs. At the same time, it can reveal both technical and design flaws. Along with a good IDE debugger, ie, Visual Studio 2005, I can maintain a statechart of what’s happening thoroughout the application.

Notice that I do not need a Sequence diagram. Why? That’s because my problem tree design specifications is already a sequence diagram by itself.

Large problem blocks or branches can then be splitted up into detailed problem view which contains the flow chart. This very simple flow chart determines how the application is to be executed and also displays the conditions and actions to take on conditions.

Once we zoom in on the flow chart blocks, we can zoom into the codes itself. From there, then we’ll start to look for the problems.

In short, I’ve reduced my investigation time to a (Log N) or less, depending on the complexity of my application.

Therefore, the key to effective debugging first comes from the design specifications document. From there, if you have the high-level problem tree, you can quickly zoom into the affected area and start looking at the neighouring areas that are involved, thus reducing the need to look in other places.

In fact, by doing it this way, it helps eliminate design-based leaks.

From the time I’ve realised this methodogy until now, I seldom have the need to tear my application apart in order to perform my investigations.

By saying this, I’m not saying that technical analysis isn’t important. In fact, technical analysis tools is just as important its design-based counterparts.

I’m saying that both ends should go hand in hand so that effective debugging can take place.

That’s all for today. Have a nice day!

Regards,

Jeremy