a) Make debugging possible
1) Think, think, think.
2) Design, design, design.
More problems have occurred by taking the wrong approach than anything else. E.g. you do not totally evaluate a module, start of with, say, 3 nested If statements and end up with such a deep nesting that the last if goes off the right margin. Then you realize you should have used a state machine, but time pressures do not allow for a start from scratch. Such a module will prove to be almost impossible to debug whatever approach you use.

b)Debugging technique.
I separate bugs into two groups "logical errors" and "clerical errors". A clerical error is e.g. a wrong sequence in a push or pop stack or, in C, a = instead of ==.
The "clerical errors" are easily handled with an ICE, you see a vaule you know is wrong and go back a few steps and go "ah".
The logical errors should be handled first by staring at the function, and if that does not solve the problem, the look at it on a sheet of paper for some reason you catch more looking at paper than at the screen. The ICE comes in handy for logical errors as well, but should not be the first approach.

The last group know by two names "the bitch" and "timing errors" and typically show up as "once a month the watchdog triggers" can only be debugged by analysis in your DNA computer.

Erik