Risky driving behavior holds a lesson for engineers. I recently completed a long distance drive from Flagstaff Arizona to Santa Cruz California. The drive itself was pretty unremarkable, except for some antics by fellow travelers.
I recently completed a long distance drive from Flagstaff Arizona to Santa Cruz California. The drive itself was pretty unremarkable, except for some antics by fellow travelers.
From two lane highway 89 in the Ash Fork Arizona area to another two lane highway joining Gilroy to Watsonville California I witnessed a series of stupid stunts, destined to ultimately kill the perpetrators and maybe some innocent bystanders.
Being passed going uphill on 89 while driving slightly above the speed limit caused a bit of a pucker factor. The driver barely made it back into the lane thanks in large part to the oncoming car moving over and a liberal application of brakes on my part. There were more similar kamikaze moves on other two lane roads, but none could hold a candle to the Cadillac Escalade that passed my on a blind curve at twice the speed limit. I’m still not sure how he managed to not kill someone with that piece of brilliance.
What does this have to do with audio? After the heart-stopping pass by the caddy, I got to thinking about risk taking. Which led to thoughts about risk taking in our profession. I swear it’s true. Maybe strange, but driving 700 miles will do that to you.
It occurred to me that engineering managers and engineers will always be a bit at odds based on their respective jobs. Engineering managers manage risk while engineers’ goal is to eliminate risk. Managers must balance cost and time to complete a project with the potential for product failure in the field.
All of this thinking about risk brought to mind an experience that I had as an applications engineer in the 70s. The company that I worked for developed a demonstration application for a 4-bit microcontroller called a “Tune Tooter.” That app note spawned two classes of products: door chimes as a replacement for door bells and sound-producing hand-held games. Design criteria for the door chime required that the device operate for a few thousand hours – which amounted to more than a decade of operation. Someone else got to develop the door chime, but I got the really cool hand-held pinball game called “Wildfire.” I worked really hard fitting the code into the 4-bit MCU memory, but shoe-horned more code than we all thought could fit into the game. But what really set me back was the required reliability of the game. I was making the game pretty bullet-proof – at the cost of a few cents per game. OK, maybe it was a few dimes, I was certain that the game would work for a good long while. Then I learned an important lesson about the intended market. Executives at the toy company told me that more than 80% of hand-held electronic games were left unused before the first battery change. A one hundred hour life was more than adequate. Out came the “expensive” pull up resistors. Gone were the snubbing circuits. Poof went the individual current limiting resistors to the LED playing surface – to be replaced with a single current limiting device.
We modified the IC masks to add an open collector output for the bell sound (shaped by an external RC network) and changed resistor values to make a motion towards proper termination. I never heard of any out-of-the-ordinary product returns. And my Wildfire pinball game is in a box somewhere – working the last time I tried it about a decade ago. I'm sure tht the next time that I turn it on, Wildfire will still work. For sure it's outlived the design life.