Fourth important dimension is to talk to your friends of what you are doing and how it will work and what problems do you have. Review process and talking to some part to friends outside is also desired. Main advantage of this is self realization of mistakes. When one explain it to friend, and when he asks few questions, one self realize mistakes to be fixed or design to be enhanced.
I always do a continuity check of all power and ground pins on a bare board as soon as it's available. This doesn't take much time, and makes sure the PC design software or the PCB manufacturer didn't miss something. I also check the Gerbers before they go out to the PCB house.
If you have a package with a large ground pad on the bottom of the chip, expect that the assembly house will forget to solder it for the prototypes. In many cases, that's the only ground connection for the chip. If possible, extend the PCB artwork for the pad out from under the chip so you can heat it up with a soldering iron.
If you have programmable parts, always bring out spare I/Os to test points (vias). These are invaluable for debugging FPGA logic in real time.
Draw your schematics as if you're going to be the one debugging the board. Number your passive components in a sensible way so they're easy to find in the schematics -- I like to number all components in the same sequence as the pages of the schematics. Don't use automatic numbering: the hours you saved by not numbering the components by hand will become days added to debugging.
Draw component symbols to match the package pinout. This will make it a lot easier to debug. For BGAs, match the pad sequence on the chip itself. For Xilinx FPGAs, you can get this from the graphical chip editor. For others, BSDL will probably get you the information.
Throw lots of ground test points at the board so that you always have one nearby when scope probing fast or low-level signals. These do not tolerate long ground wires to the probes. If there is room, a connector for a logic analyzer can save a lot of pain.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...