Dog Food

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 HundredPersonProject: 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


When I was a boy, this used to be called BootStrapping. 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?

-- PeterMerel

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: http://www.ugrad.cs.ubc.ca/~cs411/lecture_notes/02_language_processors.ppt CPSC 411: Introduction to Compiler Construction. - http://www.softwaregeneralist.ca

Kind of like DogFood 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 DogFooding?, you are using what you are making to increase quality. Wait.. that is the same thing. -- MichaelFeathers

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 AntiPattern. -- MatthewAstley

You could continue the same "bootstrapping" interpretation to BertrandRussell and AlfredNorthWhitehead'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


"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. --BetsyHanesPerry

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. -- DaveHarris

In the old days at HewlettPackard, a sign that a project was really important was that they got to use TekTronix? 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 CriticalSuccessFactorsOfObjectOrientedFrameworks 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 SelfServingSystem.

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 ArchitectAlsoImplements?. 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 (ArchitectureFollowsOrganization?) 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 ArchitectAlsoImplements?, dogfooding is telling us that ImplementorAlsoUses?. Those who implement the product should be intimately familiar with its use, and be using it themselves. A SelfServingSystem is simply a special case of ImplementorAlsoUses? that increases the coupling between product, product-developer, and product-user. The transitive closure that emerges indirectly as a result of this is that UserAlsoArchitects?. This is what "closes the loop" and is precisely the goal that ChristopherAlexander was trying to achieve with things like the "OregonExperiment?" and the "MexicaliProject?".

-- BradAppleton

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.

-- ThomasMaeder

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). -- PaulHudson

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. -- ThomasMaeder

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?) BugDatabase) 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 GirlWithaPearlEarring? gives a good illustration of this.
Of course, people doing open source and Free projects and the like are eating their own DogFood 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 BootstrapInstitute started by DougEngelbart had or has a policy of, well, bootstraping this way.
Contributors: DaveHarris, MichaelFeathers, MatthewAstley, RonJeffries, PeterMerel, BetsyHanesPerry, BradAppleton, ThomasMaeder, KevinMcConnell, PaulHudson, MartySchrader, Robin Evans

See: AlarmBellPhrase

Contrast: SymbiosisWare, SwipedFromTheBestWithPride (tricky if you're not using competing product)

CategoryJargon

EditText of this page (last edited July 27, 2012) or FindPage with title or text search