Embedded Systems Design - August 2008 - (Page 45)

0808esd.p45to48 7/17/08 12:01 PM Page 45 Name Ganssle BY Jack G.Here break points Creating software prototypes A quiet “cool!” slipped from my lips as the room ﬁlled with smoke. I watched the engineer ﬁrst turn pale, then lean heavily on this elbows. Head hung low, swinging slowly back and forth, he seemed on the verge of a breakdown. All of 16 years old, I had no understanding of the poor man’s torment. With kids, a mortgage, and multiple car loans no doubt, his family lived on the American-standard brink of bankruptcy. Now, due to a simple mistake, he had smoked a $40,000 system due for delivery in a week. Later I learned he offered his resignation to the boss, who wisely sent him back to the lab with orders to “ﬁx that unit now!” The company was in the business of selling prototypes (always glamorized by a moniker reﬂecting a more perfect product) to NASA. Everything was a one-off design; everything was delivered to the customer. The frenetic pace of Apollo brooked no delays. My undercapitalized employer always spent tomorrow’s money on today’s problems. There was no spare cash to cover risks. In the case of the smoking ground support box, we had no spare system, nor even spare boards. As is so often the case, business issues overrode the laws of physics and human missteps: the prototype simply had to work—period. Years ago, I carried this same dysfunctional approach to my own business. We prototyped products, of course, but did so leaving no room for Prototyping software is an essential step in creating quality embedded systems and a sane work environment. Here’s why. failure. Schedules had no slack; spare parts were scarce, and people heroically overcame resource problems. In retrospect this seems silly, since by deﬁnition we create prototypes simply because we expect mistakes, problems, and, well, failure. But business imperatives have their own urgency. Can you imagine being a civil engineer? Their creations—a bridge, a building, a major interchange—are all one-off designs that simply must work correctly the ﬁrst time. We digital folks have the wonderful luxury of building and discarding trial systems. Software, though, looks a lot like the civil engineer’s bridge. Costs and time pressures means code prototypes are all too rare. We write the code and knock out most of the bugs. Version 1.0 is no more than a ﬁrst draft, minus most of the problems. Though many authors suggest developing version 1.0 of the software, then chucking it and doing it again, now correctly having learned much from the ﬁrst go, I doubt that many of us will often have that opportunity. Schedules are just too frenetic, workforces too thin, and timeto-market pressures too intense. The old engineering adage “If the damn thing works at all, ship it,” once only a joke, now seems to be the industry’s mantra. 45 Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at jack@ganssle.com. www.embedded.com | embedded systems design | AUGUST 2008 http://www.embedded.com

Table of Contents Feed for the Digital Edition of Embedded Systems Design - August 2008

Embedded Systems Design - August 2008 Contents Number Include Parity Bit Programmer's Toolbox Cover Feature: Virtualization for Embedded X86 Multiprocessor Applications Wanted: Industry Standards for Benchmarking Embedded VMM Hypervisors Achieving Cache Coherence in a MIPS32 Multicore Design Memory Allocation in C Advertising Index Break Points Marketplace

Embedded Systems Design - August 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.