That has absolutely nothing to do with the fact that all of that "research" has to precede even the documentation. No coding should take place until the end-product is defined. It can't be defined until the hours, month, or centuries of research, among other things, are complete.

After that, and the rest of the 95% of the job that is the documentation is complete and approved, you can have people start to work on coding. If they can't figure out how to code what's set forth in the formal requirements, you've got the wrong people working on it and should immediately replace them ... even if that includes yourself. Properly developed requirements are not uncodeable, however, and generally fall right into place. On microcontroller projects, it should be pretty straightforward, as they're most generally VERY small, i.e. <<250k lines. Partitioning coding assignments on a large, e.g. >10M-line programs is much more complicated and requires serious management talent to accomplish, as well as careful team selection.

When you find someone who can code a melon, please send me his contact information.

i think what you've written about reducing that board in size is complete nonsesne. If you know what the circuit does, how and when it does it, etc, then how big the board is makes little difference. If you haven't completely screwed up the hardware design, the requirements documents still apply, and coding can proceed once the hardware is specified.

RE