[Editor's Note: This was originally posted on the Embedded Master]
Earlier this week, I discussed “dogfooding” – the practice of using your own product in the course of doing your business – as a robust design principle. This principle seems to be popular with a growing number of software tools providers, such as compiler providers or GUI platform development tools. I wonder if there is an equivalent principle for embedded developers especially because many embedded components are not really end products by themselves – hence they do not lend themselves to being explicitly used in a classic “dogfooding” fashion.
The primary tenet of using your own product is that you, as the designer, will explicitly understand how your product does or does not adequately support the needs of the person using your product to solve whatever problem they are using it to solve. Because this tenet is not limited to software tools, I started looking through my own experience, and that of my wife’s, who has been a program manager for many types of electro-mechanical embedded components, to identify any best practices that we used to provide the same type of visibility to the system designers that “dogfooding” is supposed to provide to software developers.
My design experience is overwhelmingly based on path-finding and prototyping projects where we were not even sure that what we were trying to accomplish was even possible. This is in contrast to improving an existing design, with an existing production customer, to accomplish incrementally more while costing less, using less power, and providing higher reliability. Once I started hearing companies using the phrase “eating our own dogfood”, I began to realize that we performed an embedded design equivalent to this concept during our system integration process. In these types of projects, demonstration and validation prototypes are a very important part of the delivery schedule because that is where we worked directly with the customer to integrate the delivered component into an actual system, real or simulated.
During the earliest integration stages, we would find many details that we needed to change because what was captured in the specifications did not always work quite as expected within the entire system once it existed in the real world. This process was essential to enable the designers to better understand how their design trade-offs affected the usability of the component, and it led to ultimately being able to more quickly deliver the component that the customer really needed and could use in the production system.
How important is it that the companies that supply you the tools and components you use in your designs practice this robust design principle? Also, do you employ any best practices, formal or informal, that you use to provide your designers with this type of insight so that they can more quickly and effectively implement the changes to your product design to meet your customer’s needs?
Processor Tracker
All Entries RSS Feed
“Dogfooding”, yet another useless bit of jargon that conveys no useful information or insight. No, I dinn’t want someone else’s rotten “dogfood”; I’ll certainly spit it out, even if the supplier eats it himself. I want effective, reliable professional tools that facilitate my development tasks!
Recall Voltaire: “If you wish to converse with me, define your terms.”
The “make or buy” decision doesn’t need dogs for understanding. By the way, both human food and dog food declare their ingredients. Some microcontroller manufacturers offer entry-level routines at no charge (good and proven example: Microchip).