People
All of us have worked with that creative genius who can build anything, who pounds out a thousand lines of code a day but can never seem to complete a project. Worse--the fast coder who spends eons debugging the megabyte of firmware he wrote on a Jolt-driven all-nighter. Then there are the folks who produce working code devoid of documentation, who develop rashes or turn into Mr. Hyde when told to add comments.

We struggle with these folks, plead with them, send them to seminars, lead by example, all too often without success. Some of them are prima donnas who should probably get the ax. Others are really quite good but simply lack the ability to deal with detail, which is essential since, in a released product, every lousy bit must be right.

These are the ideal prototype developers. Bugs aren't a big issue in a model, and documentation is less than important. The prototype lets them exercise their creative zeal, while it's limited scope means problems are not important. Toss Twinkies and caffeine into their lair and stand back. You'll get your system fast and they'll be happy employees. Use the more disciplined team members to get the bugless real product to market.

Stop the madness
The agile development approaches stress the importance of getting something working fast in order to provoke change. Show the customer a system to get lots of feedback early. There's a lot of value in employing these techniques in prototyping.

The NASA system I described smoked due to a bad power supply that took out over 100 ICs. The engineer, his resignation rejected, through heroic efforts and countless packs of cigarettes managed to salvage it, delivering it almost on time. Hours later he was deep into another high-pressure project with another impossible deadline and too few resources. He had kids to feed, so unquestioningly accepted the new assignment.

Watching this man's angst, I started to see how pressure can shrivel a person's soul. Part of management is effectively using people's strengths while mitigating their weaknesses. Part of it is also giving the workers a break once in a while. No one cranks out 70-hour weeks forever without cracking. Prototypes are always created under tremendous time pressures. But one must be realistic and recognize that humans have human limitations.

Jack Ganssle (jack@ganssle.com) is a lecturer and consultant specializing in embedded systems' development issues. For more information about Jack click here .