[Editor's Note: This was originally posted on the Embedded Master] 

Dogfooding is an idiom coined from the saying “Eating your own dog food.” Examples of companies that practice dogfooding include Microsoft and Google. Other companies, such as Amulet Technologies and Green Hills Software use the term informally in their presentations when they are emphasizing they use their own tools to make the tools they sell. CNET recently reported that Adobe is planning to provide Android phones running Flash to its employees. I interpret this to be a dogfooding moment for Adobe to ensure that Flash has the best possible chance to succeed on the Android mobile platform.

In the above examples, dogfooding spans from beta testing a product to out and out using your own product for production work. A common thread in these examples though is that they are software-based products that target developers; however, dogfooding is not limited to software. As an example, many years ago, my brother worked at a company that built numerical control tooling machines that they used to build the product they ultimately sold.

The purported advantages of using your own products is that it proves to customers that you believe in your own product enough to use it. However, the claim that using your own product means you catch more bugs and design flaws is not a strong claim because it might suggest that the company’s QA process is less effective than it should be. One of the biggest advantages of working with your own products is that it means that your developers are more aware of what works well with the product as well as why and how they could improve it from a usability perspective. In essence, working with your own products makes it more obvious to the developers what the differences are between how you think the product works and how well it actually does against what you envisioned it would do.

However, as a best practice concept, dogfooding needs to take on a different tact for embedded developers. Using the embedded system as an end product is usually not an option because embedded systems make up the invisible components of the end product. The mechanisms to dogfooding an embedded design occurs during the demonstration and validation steps of the design and build effort when the designers, integrators, and users of the embedded system work together to quantifiably prove whether the requirements specification for the embedded system was sufficient. It is not sufficient that the embedded design meets the requirements specification if the specification was lacking key information. Often, at the demonstration and validation phase, the designers and users discover what additional requirements they need to incorporate into the system design.

In short, dogfooding is that step where designers prove that the system they envisioned actually does what the end user needs it to do. In the case of embedded systems, proving out the concept to reality requires a cooperative, and often an iterative, effort between the designer, system integrator, and end user.

This entry was posted on Monday, May 10th, 2010 at 4:29 pm and is filed under Robust Design. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.