I also believe in "bottom-up" programming where you add as short as possible new code that you can test reliably, and do things like write a value to an unused port for visualizing intermediate values in calculations. One thing to look out for is interrupt processing times and priorities. If you have an interrupt routine that disables other interrupts during it's processing, you really need to evaluate the impact that these other "delayed" interrupts can have on the system. The same goes for stack space, you need to look at the worst case scenario whereby your mainline could be in a called routine containing a few "Push"s, then a regular interrupt occurs, then a priority interrupt - containing calls of it's own...