The Difficulty of Dogfooding

Joel, on the merits of dogfooding:

Eating your own dog food is the quaint name that we in the computer industry give to the process of actually using your own product.

delicious dogfood!

I had forgotten how well it worked, until a month ago, I took home a build of CityDesk (thinking it was about 3 weeks from shipping) and tried to build a site with it. Phew! There were a few bugs that literally made it impossible for me to proceed, so I had to fix those before I could even continue. All the testing we did, meticulously pulling down every menu and seeing if it worked right, didn't uncover the showstoppers that made it impossible to do what the product was intended to allow. Trying to use the product, as a customer would, found these showstoppers in a minute.

Eating your own dogfood is clearly a good idea, but it hasn't worked out too well for me in practice, for the following reasons:

  1. Developers usually aren't the intended audience

    Microsoft originally popularized the term "eating your own dogfood" during the development of Windows NT, when Dave Cutler insisted that the coding of the OS be performed under the current builds. If you're writing software intended for other developers-- or an operating system intended for the entire world-- then dogfooding makes perfect sense. Who better to test Visual Studio than the developers writing Visual Studio? There's no question that this results in a higher quality product, but you also have to be extremely careful. If the application you're writing isn't intended for expert users, having the developers dogfood it won't necessarily buy you much, because developers are highly unrepresentative of typical users. Beyond fixing critical bugs, it could even hurt the application: developers tend to add advanced, complicated features that are useful to them.

  2. The application requires specialized business knowledge

    I've worked on a number of applications that I could barely test, much less use. I had no idea what valid inputs even looked like! Sure, I had the specifications, but there's a huge difference between applications designed for general purpose use (ala Joel's CityDesk example) and custom applications designed to be used internally. These internal apps are typically quite specialized; you'd need a lot of exposure to the target audience before you could begin to think like your users. Moreover, their job may be radically different than yours; expecting software developers to dogfood an app intended for stockbrokers is probably unrealistic.

  3. Dogfood tastes bad

    It is called dogfood, after all. And no sane person relishes popping open a can of Alpo for lunch. Aside from the frustrations of using alpha and beta software, I've also worked on a number of team projects where I was never comfortable with the quality and featureset of the product we were producing. I could barely bring myself to use our own software! Since I wasn't the project manager, I had no formal authority to dictate the quality or features of the product I felt we should be building. On projects where I am the only developer, however, I can code to exactly the quality and feature level I'd like to see. The only dogfood guaranteed to taste good is your own. And even that is debatable. All other dogfood is unpleasant and often inedible.

Now, none of this is intended to discourage you from dogfooding. I just feel it's difficult to achieve for typical development teams. Not every application is as easy to dogfood as Windows NT, Visual Studio, and CityDesk. But for every obstacle I listed, there are a half-dozen benefits you'll derive if you manage to pull it off. It's clearly a best practice and you should be aggressively dogfooding your own software whenever possible:

Do what you can to incorporate your product into your job. If you are developing a word processor you should be using it any chance you get to create your own documentation. If you are developing blog software, then blog about your progress. Do whatever you can to give yourself a different perspective of the software you intend to create. The more views of something you have the more defects you will find. If you are developing a product that you can't integrate into your day to day job then you should be creating a dogfooding test plan where you and interested customers spend dedicated time using the product the way it is meant to be used. It's especially important to get feedback from these different perspectives and incorporate it into your release. Because if 1 of 20 people find a problem with your software then you can imagine the issues that will be found when you have thousands of different perspectives on your product.

And if you can't dogfood, consider working the help desk for a few days. I'm serious. There's nothing quite as effective as sharing the customer's pain.

Related posts

Complaint-Driven Development

If I haven't blogged much in the last year, it's because we've been busy building that civilized discourse construction kit thing I talked about. (Yes, that's actually the name of the company. This is what happens when you put me in charge

By Jeff Atwood ·
Comments

The Rule of Three

Every programmer ever born thinks whatever idea just popped out of their head into their editor is the most generalized, most flexible, most one-size-fits all solution that has ever been conceived. We think we've built software that is a general purpose solution to some set of problems, but

By Jeff Atwood ·
Comments

Today is Goof Off at Work Day

When you're hired at Google, you only have to do the job you were hired for 80% of the time. The other 20% of the time, you can work on whatever you like – provided it advances Google in some way. At least, that's the theory. Google&

By Jeff Atwood ·
Comments

Coding Horror: The Book

If I had to make a list of the top 10 things I've done in my life that I regret, "writing a book" would definitely be on it. I took on the book project mostly because it was an opportunity to work with a few friends

By Jeff Atwood ·
Comments

Recent Posts

Stay Gold, America

Stay Gold, America

We are at an unprecedented point in American history, and I'm concerned we may lose sight of the American Dream.

By Jeff Atwood ·
Comments
The Great Filter Comes For Us All

The Great Filter Comes For Us All

With a 13 billion year head start on evolution, why haven’t any other forms of life in the universe contacted us by now? (Arrival is a fantastic movie. Watch it, but don’t stop there – read the Story of Your Life novella it was based on for so much

By Jeff Atwood ·
Comments
I Fight For The Users

I Fight For The Users

If you haven’t been able to keep up with my blistering pace of one blog post per year, I don’t blame you. There’s a lot going on right now. It’s a busy time. But let’s pause and take a moment to celebrate that Elon Musk

By Jeff Atwood ·
Comments
The 2030 Self-Driving Car Bet

The 2030 Self-Driving Car Bet

It’s my honor to announce that John Carmack and I have initiated a friendly bet of $10,000* to the 501(c)(3) charity of the winner’s choice: By January 1st, 2030, completely autonomous self-driving cars meeting SAE J3016 level 5 will be commercially available for passenger use

By Jeff Atwood ·
Comments