Design Article
Creating software prototypes
Jack Ganssle
7/30/2008 9:00 AM EDT
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.
|
|
|
|
|
DeepNotes
7/31/2008 7:59 AM EDT
I enjoyed this article because it suggests tools and techniques that all embedded developers can take advantage of.
Regarding People, unfortunately, management does not typically have the luxury of assigning certain people to only specific phases of development. As in most companies these days, I suspect that my situation is typical - being the only developer for one complete subsystem (board/chassis management) with nobody to take over in case the bus wipes me out.
Sign in to Reply
worknhard9062
7/31/2008 8:08 AM EDT
"...with nobody to take over in case the bus wipes me out."
?
Would that be the high voltage bus, the data bus or the city bus
Thanks for the great article Jack. Spot on as always.
Steve Ciricillo
Sign in to Reply
Örkki
8/1/2008 3:40 AM EDT
Doing this sw stuff allready near 30 years I feel this article very real stuff.
I am also in situation where we have one people for one duty:
firmware, PC-apps, tester, mechanics ...
And its wery unwise at least in certain reasons:
-risk management
-costs
-peoples healthy
-memory and capability restrictions we all have as one person
-quality
-etc, etc .. .
In my opinion rotation with duties should perhaps give us more perspective for the product we are building: firmware developer starts for testing for a while, tester can make sw etc.
Of course above is resource and company culture depended...
I am not so hopefull of those new tools Robert mention due:
-longer learning curve
-investment costs
-probaple incoming complexity of work flow
-etc.
Jack mention a spreadsheet its indeed a very good project management tool also:
-first page can have some overall project metrics generated form next pages ..
-second page has history listing
-every other page has different module topics(topics,time aprox., to do lists, ...
-you fill this spreadsheet daily 5 min approximately
-last page has version list with comments of corrections,modifications
-etc.
And lastly Jacks comment of people factor is true Know Your Folks, every people counts.
Great article!
Sign in to Reply
evertw
8/1/2008 5:33 AM EDT
Excellent Article!
I recently used this approach to implement a data transport protocol. There were specs on the protocol, but they only defined the messages to be sent, not when to send them.
To solve this, I built a working prototype in Python. Took me three weeks, with most of the time being spent reverse-engineering the protocol. I also tried a few different designs. We tested the prototype thoroughly to track down race conditions.
To improve performance we then re-implemented the code in C++. The basic design of the Python code was solid, so we reused that, but we chucked all the rest. The C++ re-implementation took about 6 weeks...
Because we had built a prototype, we had a running start on the C++ implementation: we knew exactly how the code should behave, we had a solid design, and we had a stable reference to test against. This meant the C++ code was almost first-time-right. I suspect that without the prototype, the project would have taken twice the amount of time we spent.
Sign in to Reply
Michael.Lee
8/4/2008 3:48 AM EDT
I also agree the author viewpoint, the article wrote so good and point out a right way for mostly embedded project, I think , so , If you are a manager of an embedded project, maybe you should adopt some useful suggestion from this article.
Sign in to Reply
krwada
8/4/2008 7:58 PM EDT
$40k ??? I can tell you this Jack ... My wife is a project architect for the city of San Jose. A $40K boo-boo comes about twice a month in these large architectural projects! She just had to write up a change order for a $40K boo-boo that was cast in concrete ... REAL CONCRETE ... Let's get out the jack hammers!!!
Haw!
Sign in to Reply
Scottish Martin
8/5/2008 8:10 AM EDT
Good article Jack!
I have, in 28 years, found it useful to talk, write about and highlight the chasm between Protoype Code and Software Product.
Also, I like the article's analogy between protoype electronics and protoype code - the majority of customers would be horrified to take delivery of prototype hardware but are oblivious when it comes to software/firmware. One of our Software Engineering PowerPoint presentations from many years ago contained a photograph of a very rough prototype board, resembling a plate of spagehetti - we would ask managers if they were prepared to approve its delivery to a customer. It does not take a genius to determine the thread of such a conversation.
Sign in to Reply
GeneB
8/19/2008 12:28 PM EDT
Awesome article!
I have managed, lead and participated in many large and complex design projects, in both hardware and software capacities. I have always believed that prototyping software was one of the most important parts of the job.
If hardware and software are going to play nicely together, you need to get them together as soon as possible. It may not be pretty, but if you can get your software into a position where you can exercise the hardware and perform some minimal subset of functionalities that can be used to prove the concepts, you have won the first battle. Now take what you have learned and build a complete, fully functional set of software, based on the prototype that you have created.
You don't have to throw out your prototype, it can become a useful tool in managing hardware prototypes while you are busy creating the 'real' software.
Keep up the good work!
Sign in to Reply