There are three kinds of bugs/errors -- those arising from mis-wiring (like leaving out a required input or trying to connect an array where a cluster needs to go)\, errors that arise during run-time (because of division by zero, time-out, atempt to open a non-existent file), and errors arise because you used the wrong algorithm (you added when you should have subtracted).
LabVIEW's Broken Arrow catches the first class of errors. Using the Error Line and using an Error Indicator and/or the Error Handlers should trap the run-time errors, letting you "work backward" to deduce what caused them. The hardest are when the program (correctly) does what you tell it, rather than what you should have told it. There are no obvious errors, but it just doesn't work.
If your code is "doing the wrong thing", can you determine when it goes wrong? You can use a probe to monitor the contents of a wire -- among other things, not only does this tell you what data are being carried by the wire, but also when or if the data changes. Another technique that can be helpful is to include logging sub-VIs to write selected data to a text-based log file, hoping to catch both "before" and "after" glimpses of the code as the error occurs.
Often the best (and fastest) way to debug some code is to find a colleague (even one who is not familiar with LabVIEW) and explain your code to him or her. Encourage your listener to ask questions ("How do you know the number of data points to collect?") -- it is also helpful if they have some familiarity with the task you are trying to solve. In many cases, in explaining your code to someone else, you suddenly realize "Oops, I forgot to ..." -- after all, noone else knows your code as well as you do.
Bob Schor
