Why You Should Eat Your Own Dog Food, or Lie in the Bed You Make

In English it’s called eating your own dog food. In Czech we say you have to eat what you’ve cooked for yourself, or, more imaginatively, you have to lie in the bed you make. These expressions describe the purest kind of feedback you can get. Feedback is central to getting better at anything, all the more so in software development. In this article I’ll try to explain why it’s worth keeping dogfooding in mind and why it’s one of the basic rules for writing cynical software.

Weak and strong feedback

Years ago at Hewlett-Packard, customers installed the software we wrote themselves. They got a CD or DVD and a manual for their system administrators to follow. We never found out whether the software was used or how. It was a happy time in my life because I didn’t have to live with the fruits of my work. I really did live in blissful ignorance. That’s what I call weak feedback. My sense that I was doing flawless work began to wear off when I started at GoodData. I remember the turning point exactly. I was sitting with a friend in a favorite Greek restaurant, halfway into a second bottle of excellent wine, when my phone rang around midnight. Any hope for a pleasant rest of the evening vanished with one glance at the caller’s name. When the head of operations calls at midnight, it’s rarely good news. I no longer remember exactly what problem I caused, but as I ran through the dark streets of Žižkov toward our offices in Karlín, I realized I was going to have to eat what I’d cooked, every last bite. Strong feedback, if I may exaggerate a little. Even years later, I’m still sorry about that evening.

What set GoodData apart from the companies and projects I’d worked on before was that one version of the software, updated every fourteen days, served all customers. If you made a mistake, it usually affected every customer at once, and usually right away. Besides midnight callouts, another major change in feedback came from leaving behind organizational silos, where one department developed GoodData and another operated it, and moving to DevOps, with self-sufficient teams developing and running parts of GoodData. With silos, the behavior of operations staff would take a neurotic turn before each release. Developers were trying to ship everything by the end of a fourteen-day sprint, with an attitude of “commit it and let God sort it out.” Administrators were reluctant to allow any change that could even conceivably do further damage to their already fragile mental health.

Once we moved to DevOps and my team started operating our part of the system as well as developing it, I began to understand their objections. Apart from little things such as inadequate logging, I quickly learned the difference between delivering software and delivering software that can actually be operated. The experience made the team see things through an administrator’s eyes and look for ways to make administrative tasks as efficient as possible. Where we used to wave the administrators away and tell them there’d be some API for that, we now build management tools with a graphical interface. All it took was a few tries at doing some of those tasks ourselves, with our administrator showing us how.

Why it’s good to be a consumer

Eating what you’ve cooked is worthwhile when you operate the software you make, and just about any time the producer and consumer are different people. One case I’ve experienced a few times was framework development. Team A delivered the framework and team B used it. Just about the worst setup possible. Team A asks team B to define its requirements precisely. Team B does so with varying success. Team A builds to those requirements, or at least thinks it does, and hands the result over. Team B starts using the framework and gets frustrated. Team A built what team B asked for in terms of functionality, but the usability was a disaster. Team A didn’t know exactly how team B would use it. Unfortunately, team B often didn’t know either. That’s one reason the team that builds a framework should be its first consumer.

Eating your own dog food has one important effect you can see almost immediately. People and teams have much more skin in the game, to borrow a sporting expression. Developers have more fun working on something they use themselves. They’re motivated from within. Excuses such as “that wasn’t in the spec” suddenly stop. The team looks actively for ways to improve the system and takes on part of the customer’s role.

How to start eating your own food

A few simple tips to finish. For reasons I don’t understand, lots of teams ignore the first one in particular.

• Start using the product you’re developing, wherever that’s remotely possible.
• Break down the traditional division between consumer and producer and find ways for the roles to overlap. That applies to design and development or development and use, as well as development and operations.
• If you can’t break the pattern entirely, at least chip away at it with DevOps or by rotating roles. Bring developers closer to customers. If you can’t put them in direct contact, involve them in resolving support tickets, for instance.