By definition, debugging is a methodical process of finding and reducing the number of bugs in an application. Normally, the first step in debugging is to attempt to reproduce the problem. On some occasions, the input of the program may need to be simplified to make it easier to debug. Then you use the debugger tool to examine the program stats (values of variables, call stacks, and so on) and track down the origin of the problem(s), to finally be able to fix it.

Debugging however, can do so much more than just solving issues. It is a fantastic way to understand how an application works. You could just open the involved object, read the written code, and follow it up. But it will be hard.

First of all, because Dynamics NAV code is run after an event occurs. If you take a look at an object, you will see code in the events, but it will be hard to know when an event occurs, or which event is the one that first causes the code to be executed.

It will also be hard to just read the code because you don't know which values a variable is taking. If you turn the debugger on, you read the code with a specific example that makes variables take specific values. And this is really helpful!

Of course, this means that depending on specific variable values, some lines of the code won't be executed and you won't be able to follow them. Therefore, you will have to create significant and varied examples in order to cover all (or almost all) code in a given object.