Creating software prototypes
A quiet "cool!" slipped from my lips as the room filled with smoke. I watched the engineer first 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 "fix that unit now!"
The company was in the business of selling prototypes (always glamorized by a moniker reflecting 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 failure. Schedules had no slack; spare parts were scarce, and people heroically overcame resource problems. In retrospect this seems silly, since by definition 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 first 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 first 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 first go, I doubt that many of us will often have that opportunity. Schedules are just too frenetic, workforces too thin, and time-to-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.
Besides, who wants to redo a project? Most of us love the challenge of making something work but want to move on to bigger and better things, not repeat our earlier efforts.
Hardware now suffers from the same ills. Reprogrammable logic means the hardware is nothing more than software. Slap some smart chips on the board and build the first production run. You can (hopefully) tune the HDL to make the system work despite major logic errors.