The code
The goal of a prototype is to resolve unknowns, not to build a final product. Yet when the boss sees something working he's inclined to ship. A hardware prototype looks ugly; there are a zillion green wires all over the PCB. Those green wires are also in the software version but just aren't visible. "Working" doesn't mean maintainable, reliable, or even tested, so it's wise to create a prototype that might work, but that isn't shippable. So I'm inclined to eschew C and use really high level "languages" like Visual Basic. Or Excel macros. The goal is to get something going now. Use every tool, no matter how much it offends your sensibilities, to accomplish that mission.

Spreadsheets are wonderful tools for evaluating the product's science. Unsure about the behavior of a data-smoothing algorithm? Fiddling with a fuzzy-logic design? Wondering how much precision to carry? Create a data set and put it in your trusty spreadsheet. Change the math in seconds; graph the results to see what happens. Too many developers write a ton of embedded code only to spend months tuning algorithms in the unforgiving environment of an 8051 with limited memory.

Although a spreadsheet masks the calculations' speed, you can indeed get some sort of final complexity estimate by examining the equations. If the algorithm looks terribly slow, work within the forgiving environment of the spreadsheet to develop a faster approach. We all know, and too often ignore, that the best performance enhancements come from tuning the algorithm, not the code.

Does your product have a GUI? Maybe a control panel? Lots of math? Consider using products like MATLAB or LabVIEW to create a look and feel that marketing can evaluate. Coupled to standard data-acquisition boards and a bit of code, you can produce models of many sorts of embedded systems in hours.

The cost of creating a model of your product is tiny compared with designing, building, and troubleshooting real hardware and software. Although there's no way to avoid building hardware at some point, count on adding months to a project when a new board design is required.

Another nice feature of doing a model of the product is the certainty of creating worthless code. You'll focus on the real issues--the ones identified in your prototyping goals--and not the problems of creating documented, portable, well-structured software. The code will be no more than the means to the end. You'll toss the code as casually as the hardware folks toss prototype PC boards.

Though the PC is a great platform for modeling, do consider using current company products as prototype platforms. Often new products are derivatives of older ones. You may have a lot of extant hardware and software in a system on the shelf. Be creative and use every resource available to get the prototype up and running.

Toss out the standards manual. Use every trick in the book to get it done fast. Do code in small functions to get something testable quickly and to minimize the possibility of making big mistakes.