Good enough is exactly that

Scott Rosenthal
August, 1998

Ship it! We've all heard these words from our bosses. But what constitutes "good enough to ship"? What design tradeoffs must you make to meet market requirements? What's the difference between the design lab and the real world when it comes to shipping products? And how do these considerations pertain to embedded systems?

It's no secret that companies stay in business by shipping products. It's a simple equation: A company ships products that its customers want. They pay for the product, and you get a paycheck. If the money coming in exceeds product cost, you keep a job and probably also get adequate tools to do a better job. Conversely, if you don't ship any products, no payments arrive from customers, and you lose.

The embedded software realm is quite different from other engineering disciplines when it comes to what's good enough to ship. In the mechanical world, people can touch and feel an engineer's product. Rigid rules exist for what will and won't work. For example, a finger hole to open a cabinet must be at least a certain size, or the force to turn a knob must be less
than a certain value. Designers can fall back on commonly accepted criteria during product design.

In the embedded world, though, you won't find accepted norms for what is and isn't acceptable. A simple example of this free-for-all is the beep that sounds after a keypad press:

	Should there be a beep at all?
	How loud should it be?
	How long should it sound after a keypress?
	What should it sound like?
	If the user holds down a key should the beep also repeat?
	Should the user have the option to disable the beep?

Obviously, someone must answer these questions before finishing an embedded design. Further, you can probably see that some of these issues concern software, while others relate to hardware. So what happens if-after carefully studying all these tradeoffs, designing the system and getting it ready to ship-someone (such as a potential customer) decides that the beep implementation is substandard? Do you ship the product? Do you redo everything possible in software and ignore hardware changes? Or do you implement all the changes?

To ship or not to ship?

Unfortunately clear-cut answers don't exist. So I turn to a handy rule of thumb when determining whether or not to ship: if the "problem" won't impact sales (and thus money flowing into the company), I recommend shipping the system and ignoring the problem for the present. If the problem causes an impact on sales, you must estimate the cost of the problem and the solution-and don't forget the possible expense associated with delayed market entry, disappointed customers and bashing by the competition.

If you noticed, I said to ignore the problem for the present. Every product I'm working on has an associated wish list. This list should contain ideas for improving the product including new features and manufacturing improvements. Then, at regularly scheduled times, perhaps twice a year, the design team weeds through the list, keeping what makes sense while
discarding outrageous ideas and scheduling the next release.

Such incremental improvements allow continued shipping and keep cash flowing while tuning the product to market needs. Yet some companies won't release a product until it's perfect. Unfortunately, in reality a perfect product never exists, and trying to design one takes an inordinate amount of time that can sink a company. I remember reading that Sony introduced a new Walkman every three weeks instead of trying to design the ultimate unit. While most of us couldn't produce a new model at that rate, we can learn to ship a product when it meets most marketplace needs. Understand that I'm not advocating letting the customer debug the product. But you must make a conscious decision as to when it's good enough to ship.

Hardware vs software

Another major "what's good enough" criterion for embedded systems comes from deciding what belongs in hardware vs software. I've seen products designed with three major philosophies:

	Put as much as possible into software and ignore the extra processing power the system might need.
	Put as much as possible into hardware to reduce the software chore.
	Implement in hardware whatever you're familiar with and then use software to implement the stuff you don't know how to handle.

The tradeoff between hardware and software presents a difficult decision for most products. I've probably spent more time making these tradeoffs than actually designing hardware. Remember, too, that hardware brings along a recurring cost for every unit produced, and don't forget that the more hardware a product contains, the more chance that a unit can fail in the field.

Software design and complexity, though, can quickly overwhelm the cost savings of moving features over from hardware. I try to anticipate the future, think about what might change within the product and how the design (both hardware and software) would change to accommodate the requirements. For example, on a measurement and control system, the following often change:

	The loop-control time might decrease for better control.
	The system might store more parameters than the initial requirements spec'd.
	The required analog resolution will probably increase with time.
	The math-processing requirements will probably increase.
	The system might need more analog inputs to handle additional sensors.

Just like practicing defensive driving, you can also design embedded systems with caution. In the above example I'd probably create a system with the following features:

	One or more extra analog input channels, if these channels won't easily fit into a design, leave room-not just board space, but also chip-select lines and loading capacity-for an additional chip you could later load if needed.
	Make sure processor bandwidth has sufficient room to add 50% more capability. Today this aspect generally doesn't significantly impact processor cost, but it could affect the device's EMC characteristics and power usage.
	If not outrageously expensive, design in an A/D with more bits of resolution than what the application presently calls for, such as going from a 10-bit to a 12-bit converter. Again, the upgrade entails little cost difference, but it might extend the life of a product line.
	Design software to easily allow additional sensor inputs for use in the control loop or for recording control quality. Good structured design with object-oriented philosophies easily allow new features without destroying existing code.

One thing I do try to avoid is eliminating any hardware control loops. Sometimes they're necessary, but if the software does this chore, you'll have more control over future changes, plus it'll be easier for a technician or ATE device to diagnose a problem.

Real world vs the lab

Another potential problem involves designing a product that, in addition to meeting market needs, must also adhere to a design lab requirement. Too often, lab standards dwarf a product's real-world requirements. For instance, medical devices often need an R&D mode that allows users to bypass calibration and gather data for trials. Once the product ships, though, it must operate in clinical mode where you don't give users access to critical setup data and don't need to pay for data logging. The additional complexity drives up both production cost and the design effort. Be careful going down this path. It's too easy to design something for the lab and forget about the product's intended use and where the company's money comes from. If the lab really needs special requirements, it might be better to design a parallel product instead of saddling the production model with the needs of just a few. I've driven down this path, and each time I've been challenged to focus on the product and keep away from lab needs. PE&IN

Adapted from an article that appeared in Personal Engineering & Instrumentation News.

Return to the article index.