This article is part of my online newsletter called the Scrum Addendum. If you enjoyed this article you should signup for the complete series.
The concept of “dog fooding” your own products has been around for a long time, and has been made famous my Microsoft who are rumoured to practice “dog fooding” their products as a regular part of their culture. What is dog-fooding?
To say that a company “eats its own dog food” means that it uses the products that it makes … The metaphor of a company “eating its own dog food” takes this idea one step further to say that the company has not merely considered the value of the product for consumers (that is, whether the dog will eat the dog food), but actually is a consumer of the product. – Wikipedia
The case for “Eating one’s own dogfood”
Dogfooding is generally considered a good thing because it provides early feedback to the development team and allows the the product to be used in ways the team never envisioned. There are also marketing reasons why using one’s own product is advantageous.
The benefits of dog-fooding, however, are based upon the assumption that high quality software is released to internal customers. This assumption is fraught with danger because we know from experience that software quality (in general) is very low. So, what happens when poor quality software is released to internal customers and they are expected to consume it? How does this affect the behaviour of the development team, and their internal customers?
Dog-fooding as an anti-pattern
“Eating one’s own dog-food” becomes an antipattern when software quality is low and internal customers are treated as an extended QA team. This can happen when the team are pushed to meet a scheduled deadline without proper regard for the quality [of the software]. When this happens the burden of comprehensively testing the product is often shifted to the captive internal customer base.
When this behaviour is repeated over a period of time, relying on the feedback of internal customers becomes an excuse to deliver poor quality software; why perform comprehensive testing when your captive audience will find the bugs for you? Dogfooding becomes a safety net rather and a competitive advantage.
Symptoms that dog-food is poisoning the food chain
When poor quality software is propagated throughout an organization it can have a huge effect on the organization’s ability to quickly and easily release software.
Teams that are dependent upon the dogfood are forced into depending upon poor quality software with numerous issues and defects. Internal customers are negatively impacted when patches are rolled out. I have worked with at least two large clients who have had great difficulty releasing software in part because of the poor quality of the dog-food. Symptoms of dog-food poisoning include:
- Dogfooding is mandated by senior management, often against the wishes of the team
- Patches and Upgrades have unforeseen impact on projects that are several degrees removed
- Internal customers are resistant to accepting patches and upgrades, and
- Internal customers using other (unapproved) tools and products without fully informing management
Alternatives approaches to Dog-Fooding
To be clear I’m not suggesting that dog-fooding has no place. I’m attempting to point out that when poorly executed the practice of dog-food can have a very large negative impact on an organization. If the practice of dog-fooding has any merits what must be done to experience those benefits?
- Treat all clients whether internal or external the same. I feel that this is really the issue at hand. Treating internal clients as an extension of the QA cycle is a poor excuse for not delivering high quality code. It’s important to understand that the time and attention of internal clients is as important as external clients. Treating both with respect will greatly improve both the relationship and ultimately the quality of software produced.
- Only release high quality software. This sounds like an obvious statement, but when so many companies have trouble producing high quality software I feel that it’s worth stating. High quality software means software that has (at the very least) been built, unit tested, integrated, and functionally tested with no outstanding bugs.
- Finally, allow for competitive selection of tools from the marketplace. Allow teams to select their own products and tools, and then listen to them very carefully when they don’t eat the dog food. If the team is selecting an external tool over the internal tool, there must be a reason for it. Is the external tool easier to use? Is it more flexible, or more easily customisable?
To summarize, dog-fooding is the practice of using the same products that one creates. The practice of dog-fooding needs to be predicated by high quality software to be effective. Dog-fooding should not be used as an excuse for releasing poor quality software. Releasing poor quality software into the food chain results in dysfunctional behaviour that makes it more and more difficult to release high quality software.
Only by continually focusing on releasing high quality software can dog-fooding be an effective practice.