Dog food is sold to the owners who buy it, not to the dogs who have to eat it. "Eating your own dog food" is a metaphor for a programmer who uses the system he or she is working on. Is it yet functional enough for real work? Would you trust it not to crash and lose your data? Does it have rough edges that scour your hand every time you use a particular feature? Would you use it yourself by choice?
"Programmer as user" is good for the kinds of programs that programmers actually use, like operating systems, text editors, word processors, class libraries, compilers, debuggers, GUI layout tools and such. However, you should remember that not all users think the way programmers think.
From Hundred Person Project: When I said "dog fooding" I was referring to the practice of developers using the code that they develop. I heard the phrase first in the context of Windows NT, where after a point the developers ate their own dog food: used the operating system during development. If your team is being paid using their own system, then they are "dog fooding." A feedback cycle is in place. Kind of like Henry Ford's solution to pollution: you can only pollute upstream from yourself.
It doesn't have to be just the programmers. I was once at a talk by Phillipe Kahn when he was starting up Starfish, and they were developing a program that, among other things, included a straightforward word processor. It was company policy that everyone had to use this word processor for their correspondence, to find bugs and to ensure that it was usable by non-programmers too.
Could we start to summarize by listing purposes, examples and amusing failures?
Purposes
to attempt to create a Feedback Effect loop to improve quality
to publicize some product or improve its reputation - "See, we eat it. It can't be so bad!"
where the product is in some way "viral", to try to seed a user base
When I was a boy, this used to be called Boot Strapping. Especially wrt compilers. But searching online it seems like that must have been colloquial, which kind of surprises yours-truly. Anyone else have "bootstrapping" used like this?
-- Peter Merel
Doesn't bootstrapping
refer to the process of bringing up a compiler on one architecture by cross-compiling it on another architecture?
Bootstrapping... to pull one's self up by one's own boot straps. In compilers, this is when you write the compiler in the language that it compiles and then alter the code generator so that so that you can compile the compiler and thus port it to a new architecture.
I just googled for '"compiler construction" bootstrap' and found a few relevant items. Here's a good introduction:
www.ugrad.cs.ubc.ca 
CPSC 411: Introduction to Compiler Construction. - www.softwaregeneralist.ca
Kind of like Dog Food in that it is the same conceptual structure but with different intentions. In bootstrapping, you are using what you are making to decrease work. In Dog Fooding, you are using what you are making to increase quality. Wait.. that is the same thing. -- Michael Feathers
Yes, compiler construction would be my default expected meaning for "bootstrap" and I do see it as a form of dogfooding. That some systems take it to the extreme, so can only be constructed a working version of itself, is probably an Anti Pattern. -- Matthew Astley
You could continue the same "bootstrapping" interpretation to Bertrand Russell and Alfred North Whitehead's attempt in Principia Mathematica to formally reconstruct contemporary mathematics entirely from scratch. At any given point they were only allowed to use what they had constructed up to that point (including constructing the rules that determined the conditions under which it was usable). They got as far as defining rational numbers before running out of steam, but reckoned they had made their point.
Examples
many mozilla and bugzilla bugs mention "dogfood" bugzilla.mozilla.org
Certainly the C3 people were interested because their payroll program was going to pay them, but that's not quite the same as writing code using the editor you're writing code for. The Chrysler people used to check their own paychecks as part of inspecting the system, because it was one they were familiar with. -- Ron Jeffries
According to gossip within the technical writing community, Microsoft documentation is supposedly produced using a hotrodded version of Word. This is necessary because Word doesn't work well for large (>100 pages is the usual number) documents, and Microsoft requires its writers to "eat their own dogfood". The gossip doesn't explain why Microsoft never ships the hotrodded scalable version to customers. -- Betsy Hanes Perry
I've never seen that hotrodded version of Word, but I've seen many tools at Microsoft that should be turned into real products, but somehow Bill doesn't realize that they have built awesome side-products that nobody outside Microsoft even imagines. The most interesting thing is that this side products were built to scratch an itch, just like in the open source business, therefore it must be hard for developers to recognize they have actually spent time writing stuff that they thought they needed and no manager is aware of...
A friend of mine once wrote a debugger for the Atari Falcon, and before long he was using his debugger to debug his debugger (as it were). He told me that it got so visually confusing at times that he ended up making builds of it in different colors, just so he could tell them apart! -- Kevin Mc Connell gdb has an option to change the prompt for just this reason... I guess it wouldn't just be visual confusion either: "Is this a bug in the debugger or a bug in the debugger debugging the debugger? Bugger." I never metabug I didn't like.
I work at the IBM lab where the open-source Eclipse platform (which includes a fully-featured Java IDE) is developed. The phrase 'eat our own dog food' is used frequently in a positive sense: all the Eclipse developers use Eclipse every day to do their development. In this case, a nice side benefit of making Eclipse as good as possible is that it becomes a more powerful tool for making Eclipse as good as possible.
I did a gig at a well know medical products company in the far western suburbs of Chicago some years ago. The product was an apheresis machine; a device that extracted platelettes from whole blood and put everything else back in your veins. I treated this product like any other medical device I've ever touched: would I want my mother to be hooked up to this thing? So, I went through a couple of procedures myself to see what it was like. Pretty cool. Sadly, I never got a chance to test any of my code changes on myself. The V & V cycle was way too long. However, I was prepared to eat my own dog food, A Double Plus Roger That.
I use emacs to write emacs customizations.
Wolfram Research makes publicity fodder from the statement that its web sites, and its application/documentation test/build processes are all Mathematica Language-driven.
"Eating your own dogfood" can be disastrous when, as in many large companies, there's a disconnect between the developers and the in-house users. I worked for one large company which insisted that documentation be created using the company's own in-house documentation markup language. The problem was, the developers who worked on the markup language were in a different division (and a different timezone!) from the people who used the language. The language processor was full of bugs, and the developers weren't responsive to complaints coming from outside their division. As a result, the writers developed a "known safe" subset of the language, and spent a lot of their time coding around bugs.
So I guess I'd modify the proverb to "If your developers don't want to eat their own dogfood, find out why." Forcing people to use company products when they don't want doesn't help either the tool or the tool user.
I don' t think it counts as dog fooding unless the in-house users can influence the quality of the product. The aim is to get the benefit of the feedback, and your two examples show failure there. In the Word example, the people producing the manual are manifestly not using the WP they are documenting. -- Dave Harris
In the old days at Hewlett Packard, a sign that a project was really important was that they got to use Tek Tronix oscilloscopes instead of the HP ones, which weren't quite as good.
I am moving this over here per Dave's suggestion to a comment I made on the Critical Success Factors Of Object Oriented Frameworks page. I talked about how a good framework tends to evolve by actually using its own parts to provide broader and deeper functionality. This is and example of something I call a Self Serving System.
As Dave describes, there is a beneficial effect of this. It is more than just the developers being users and staying intimately connected to the user's viewpoint. There is a kind of completeness, a proof-of-concept, if the system is able to use itself. If, in theory, the system might be used on itself this way (and its not always possible for a lot of systems, like stuff to control nuclear arms ;-) then if it cannot handle itself, there is usually some inconsistency somewhere that needs to be worked out (though now we start treading into Goedelian territory ;-)
Cope has a pattern called Architect Also Implements. It states (briefly) that the designers need to have their hands dirty in the implementation. Part of it is about designers being socially connected with implementers. Conway's Law (Architecture Follows Organization) tells us that the system structure will reflect the communication structures of those that produced it. Part of it is also about those who do the "high level" stuff having intimate awareness of the technical details regarding the other perspectives. This relates to feedback (and feed-forward) loops.
In the same vein as Architect Also Implements, dogfooding is telling us that Implementor Also Uses. Those who implement the product should be intimately familiar with its use, and be using it themselves. A Self Serving System is simply a special case of Implementor Also Uses that increases the coupling between product, product-developer, and product-user. The transitive closure that emerges indirectly as a result of this is that User Also Architects. This is what "closes the loop" and is precisely the goal that Christopher Alexander was trying to achieve with things like the "Oregon Experiment" and the "Mexicali Project".
I have experienced that dogfooding works very well if you have distinct groups using the tools they develop. If you have a single, coherent group of developers, they tend to tread the same old trails over and over, thus not getting good coverage. Dogfooding helps you a lot in prioritizing your bugs. When you really use a product, you immediately spot the things that really annoy you and also those you can live with. Anyway, I think dogfooding improves perceived product quality a lot.
I think this (developers using their own product) can be an anti-pattern, if the developers are allowed to influence the direction of the product so it suits them. Sometimes the developers are not good analogues for the customers. This is most dangerous when there is some relation between the product the customers want and the product the developers want. I've seen this when a development team was asked to develop a product for large teams of developers in large corporations. The product was developed in itself. The development team was small, highly technical, and not expert in the customer domains. They had a lot of input into the product's ongoing development, and the result was (in my opinion) a poor fit for customer needs (of course, it's really a failure of product marketing/management to not manage this). -- Paul Hudson
I totally agree as far as the feature set is concerned. However, dog fooding exercises the basics of the product, the things you do all the time. My experience is that if you let enough people do serious work with something, you will catch a fair amount of bugs. The user (even if it's a developer) is a pretty good random generator of test cases. I guess the assumption behind dogfooding is that your task has enough in common with the customer's that the experiences you make in dogfooding are a good approximation of what the customers will see. The Microsoft example above is actually pretty good. If MS did take their dogfooding experiences seriously, we would have a more scalable Word. -- Thomas Maeder
Another example from long ago of Microsoft's institutional dogfooding: I was there in early '95 (it might have been late '94) when a memo came down from somewhere on high - it might have been one of the rare missives from billg himself. It advised everyone to load the new Windows95 onto their work machines and to begin using it as the standard operating system. I was happy enough to do so since I detested Windows 3.2. I don't recall any particular problems that I had, but I did notice that apparently unrelated problems started cropping up on the network. Email was frequently going down. Raid (the (in house?) Bug Database) was often inaccessible. Even nearby servers and printers would disappear.
A few days later, a second memo from a lower level arrived through the network mess advising everyone to remove Windows95. I don't recall the exact wording, but I believe that it said something about "network issues" that had to be addressed. I wasn't in that group and hadn't been there for very long, so I didn't hear much more about it. But shortly thereafter, stories started cropping up in the press that the planned release date for '95 would be pushed back - maybe to as late as September.
Dogfooding had worked in that case as it has in several less spectacular cases as they introduced pre-release Exchange servers onto the busy microsoft.com domains. -- RobinEvans
I worked for a company where this phrase was used every week. It was used by managers that wanted developers to use the UML modeling tool we were developing. We tried but always gave up. Not because of problems in the tool but because UML modeling didn't make our lives easier or our software better.
The moral of this story: beware of people who repeat this phrase. If the dog food is really good you'll eat it no matter what anyone says.
Using your own code is reminiscent of how renaissance artists had to make their own paints. The movie Girl Witha Pearl Earring gives a good illustration of this.
Of course, people doing open source and Free projects and the like are eating their own Dog Food simply because the thing at hand is made because they need (or want) it.
There was a recent interview with the head of IT at Microsoft, that I can't find now, where he talked a lot about dogfood. Apparently one of his policies is that all of the infrastructure uses MS products.
On a personal note, though, I find that focussing on your own products like that can end up blinding you to problems too - you become so used to them that workarounds become almost subconcious, and you just don't do things your product can't do. Eating your own dog food is great, but you have to keep your eyes open on the wider world, too.
Dogfooding also applies to management consultants. If your method is so great then why don't you use it? The Bootstrap Institute started by Doug Engelbart had or has a policy of, well, bootstraping this way.
Contributors: Dave Harris, Michael Feathers, Matthew Astley, Ron Jeffries, Peter Merel, Betsy Hanes Perry, Brad Appleton, Thomas Maeder, Kevin Mc Connell, Paul Hudson, Marty Schrader, Robin Evans
See: Alarm Bell Phrase
Contrast: Symbiosis Ware, Swiped From The Best With Pride (tricky if you're not using competing product)
See original on c2.com