Dogfooding

Jeff Atwood discusses a particularly vivid example of "eating your own dogfood". In software development, this means using the software you make, thereby displaying confidence in your product.

While I am a big fan of the philosophy, this doesn't really work if the software you make is not for a mass market or for developers. My jobs over the past decade have been creating trading systems and international shipping tracking. Not much use for that on my own desktop.

However, in an earlier post, Jeff says

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.

I can't agree more with Jeff's suggestion. Not only do you get a great view of what your customer is thinking, but you get a great view of what the team is thinking.

As managers, we sometimes get the idea, "Hey, I'm a manager now, I don't develop anymore." Or, as developers, we sometimes think, "Hey, I'm a developer, I don't do QA."

Yet, dipping one's toe in these other areas pays innumerable benefits. Some companies train their managers with a starting rotation on the front lines; I'm completely in favor of that.

In a previous job, I was put in charge of a fairly large group, where the programmers did both development and support. I took some shifts working the "hotline", taking calls from users.

Here are some of the specific benefits that came out:

• I got a deep understanding of the user's pain points (Jeff's point), which helped with decisions about priority.
• I talked to and developed relationships with a set of users I might not have otherwise me.
• I got a deep understanding of the cost of the user's problems, which helped with decisions about resource cost (for both fixing and not fixing).
• The technical and business skills and knowledge of each developer became apparent when trying to find the right people to help with a given problem.
• I combed through the code first-hand, getting a view of its quality and organization.
• I had to familiarize myself with the dev tools and processes.
• I received a first-hand view of how the team worked together.
• These activities were not viewed as "management prying" because they were part of an actual goal-oriented effort.
• Based on this knowledge, I devised a more efficient support and development schedule.
• Because the schedule was based on line experience, it naturally included many of the developers' own concerns, and not just a plan "dropped from the sky".

You will notice that almost all of these benefits accrued to me. Sitting on the help desk was not an exercise in altruism, or a heroic symbolic gesture.

This is not dogfooding in the traditional sense. However, being forced to live in the environment that surrounds you, that you contribute to -- developers taking a QA turn or going on a sales call, managers taking a developer turn or answering the hotline, etc. -- is the same philosophy applied differently.

Dogkenneling, perhaps?