Engineering is a precise discipline. We test, we measure, we simulate, we construct. We solve problems based on tangible criteria, experience, and time-tested formulae. And then we put our products into the hands of standard-issue humans and everything falls apart.
Embedded systems are where precise engineering meets erratic human nature. No matter how carefully we craft our latest design we just can't account for the apparent chaos that reigns among our customers.
Consider the evidence. It costs 99 to download a full-length CD-quality song but tinny 10-second ringtones sell for $2.50. Gasoline is cheaper than bottled water, but no one complains that Aquafina (filtered tap water) costs too much. Ounce per ounce, Wite-Out is more expensive than 12-year-old Scotch, and Pentium processors are more costly than pure gold.
We pay premium prices for logo T-shirts and become walking billboards for a company we know nothing about apart from the fact that its only business is self-promotional clothing. In a sane world, they'd be paying us for the advertising.
But that's the way the world is, and we can't predict mass—or even individual—behavior. We can be as arbitrary as we like and other people seem to be enthusiastically embracing the same freedom. That's part of what makes life tough for an embedded systems designer.
Bugs can pop up in our code because users do weird things we never anticipated. The cleverest new feature can get totally ignored because users develop habits that circumvent the very problem we were trying to solve. Mediocre products sell like hotcakes while better, cheaper alternatives sit in the warehouse. It's frustrating when engineering discipline smacks its head on the low doorway of human nature.
The lessons from this are twofold. First, design for the worst case. Build in tough and reliable error handlers and expect the unexpected, particularly if you're designing for a consumer or end-user market. Second, listen to your marketing people. Horrific as that sounds, they're paid to factor in the human element. They may not know much about engineering but they're probably a lot closer to the real customer than the average developer is.
We all know that superior products don't always sell. A better mousetrap is just that: better, but not necessarily more successful. Scientists have the luxury of assuming a mathematically ideal environment. Engineers, on the other hand, have to take reality into account. That's why we get the big bucks.