The Pros and Cons of Eating Your Own Dog Food

In the software industry, eating your own dog food – or dogfooding – is a common approach for companies to test their product or service by letting employees use it in real-life scenarios. The idea is that by using your own software just as a customer would, you can proactively validate and incrementally improve it before releasing it to the world. Besides quality control, relying on your own product also makes for good marketing.

One of my favorite books, The Year Without Pants by Scott Berkun, contains this memorable account of dogfooding, which I found to be worth quoting in length (I added line breaks for readability):

It turned out the adjustment was easy. The Internet Explorer team at Microsoft had an equivalent, called the daily build, where we released a version of the software every day, but it was available exclusively inside the company. Each day all the changes from the previous day were compiled and released, and everyone was expected to install and use them. This gave us regular feedback on the quality of what we were making, including nuggets of joy, or moments of misery, when new features were added.

On good days, the builds were high quality, and we called those releases self-host, as in “safe to host on your computer.” Builds that were mediocre were called self-test, suggesting you install it only on a test computer (or a coworker’s when the person wasn’t looking). The worst builds were called self-toast, meaning you’d destroy whatever machine you had dared installed it on. Whenever we had three days in a row with self-toast builds, all new work stopped until we got the build quality up to a good level (a measure to prevent the project from digging a dangerously deep quality hole for itself).

Shipping on WordPress.com was the same philosophy, just accelerated and made public to customers. I didn’t find the lack of bigger plans or schedules a problem. In fact, it was mostly liberating.

It’s true that dogfooding lends itself more to certain products than others. It doesn’t take a lot of imagination to see, for example, how it can be used effectively in these cases:

• Using Internet Explorer, a browser, to build Internet Explorer
• Using Basecamp, a project management tool, to build Basecamp
• Using GitHub, a code hosting/collaboration platform, to build GitHub

In each example, the product in question is a tool engineers would need for everyday software development anyway – a perfect fit for eating your own dog food. For organizations/teams who don’t build user-facing products similar to the ones listed above, dogfooding might be limited to more constrained test scenarios, or it might be impossible to implement for the system as a whole.

I’ve spent the last 18 months of my career working on a project that’s suitable for dogfooding like no other before it. Building and operating Wonderland, Jimdo’s in-house PaaS, has provided us with the unique opportunity to run most of the platform’s services on the platform itself – basically everything that can be deployed via Docker.

We don’t throw our work over to QA and wait for bug reports (there’s no QA department anyway). More often than not, we are the first to feel the joy and, more importantly, feel the pain of using our PaaS in production. Dogfooding gives us invaluable feedback on both released features and work in progress; it helps us to detect many issues before our users do.

To some degree, dogfooding has also been useful for anticipating wishes and evaluating ideas expressed by other teams at Jimdo (our customers). However, it’s always a challenge when we don’t have a real need for a specific feature. For example, back when we added the ability to run periodic jobs in Wonderland, our team didn’t have a use case for them at first, so we created a somewhat contrived cron that posted some stats in a Slack channel. That’s not ideal.

While we’re the first users of our PaaS, we’re by no means the largest. That means we might not be the first team running into scaling issues. That’s unfortunate, but it’s also a matter of costs. I’m confident that, for instance, load tests in production would come in useful here. Speaking of testing, dogfooding is no substitute for traditional automated and usability testing. Nor is it an excuse for depending on internal systems only.

There’s also the danger that developers may have knowledge to make software work that a normal user will lack. In fact, it’s common for SaaS products to expose tons of system internals when being used in “developer mode” by its creators. That’s certainly useful but also something to be aware of.

Despite these disadvantages, I’m convinced that those who develop software should ideally be the first ones to use it on a day-to-day basis.

Try hard to make your software a major part of your workflow. Put yourself in the shoes of existing or potential users as often as you can. Feed results back into the product’s design and code. Rinse, repeat. This way, overall quality and usability are very likely to increase over time.