Eating Our Own Dogfood

Eating your own dog food. Taking what you dish out. Talking the talk and walking the walk. It’s a seemingly simple concept that has very important ramifications for the entire development process. If you’re an elementary contributor, developer, or someone interested in the development process, read on to learn about “dogfooding” and why our devs and team members should do it.

Today I was, as usual, hanging out in the elementary Development channel (#elementary-dev on irc.freenode.net) where the developers discuss their development and get feedback from the other devs. Daniel Foré pointed out to someone that we should really be using our new Terminal app (pantheon-terminal) while developing, instead of the default GNOME one. A few devs disagreed, mentioning its relative infancy and some usability issues with it in its current pre-alpha form. Issues that will of course be addressed like broken tab-completion, non-descriptive window titles, and poor color contrast, which turn out to be pretty irritating when you’re just trying to get something done.

Dan stuck by his argument that we should still be using it. Not to punish ourselves, but so that we can use it in all of the complex situations other developers will be using it in the future, and so we can point out those annoying issues and perhaps even contribute to help fix them. With more elementary developers coming across the issues, more of us will want the issues to be fixed, and more of us are likely to sit down and take the time to fix it.

This theory, also commonly used by companies such as Google and Microsoft, is referred to as “dogfooding.” The idea is that an organization should use its own products. This isn’t solely due to the idea of competition (most of our devs still boot Windows, OS X, Ubuntu, and other operating systems), but so the organization’s products are tested heavily internally in real-world scenarios. Just like with Terminal, our developers should use BeatBox for their music listening so they can help point out any possible issues and improvements. We should use Marlin for file browsing so we can provide valuable feedback and differing opinions that, in the end, will help make the app rock even more. We should go to Lingo when looking up words, we should use AbiWord for word processing, we should store our contacts in Dexter. All of this so we understand how users interact with elementary as a whole.

For some, this may seem obvious. “Of course you should use what you make,” you say. But for others, this is actually a pretty difficult thing to do. These people argue that not every app is for every person, and that they prefer a different app for themselves. While they’re allowed to prefer something else (we’re all for choice, and we don’t care to shove stuff down peoples’ throats), it’s crucial that they use the elementary app, at least occasionally, so they can tell the other developers why they prefer something else. All of this helps the development process move forward. This theory of dogfooding applies to other team members, too; how are our artists supposed to design for elementary if they don’t use it? How can our journalists talk about the apps if they’re not users themselves?

If you’re a developer of elementary applications, I encourage you to eat your own dog food, and the dog food of the rest of the team. If you don’t like the way something works, let the other devs know. Or, if you’ve got the knowledge, take the time to fix it and submit a patch. If something is so broken you can’t use it, don’t just skip over it, but take some time to understand why it’s broken and what we need to do to fix it. If you’re a contributor in some other way, I encourage you to eat the dog food as well. If we’re all eating the dog food, we’ll all be focused on one thing: making it taste better.