At what point in a project should developers start to "eat their own dog food"?

Question

We have a project coming up where the PM is insistent that the team should "eat their own dog food"?

At what point is it realistic to do this?

e.g. assume we have to write an editor. We can't use this editor at the beginning to actually code because it doesn't exist. We have to use another editor.

For a while during the project, using a buggy editor is going to slow the project down and will be counter productive.

So at what point do we switch?

Update: After some discussion within the team, the points we will stress during development are:

• Implement smallest subset possible to start off with
• Identify critical features asap
• Only switch some of the developers to use the new product to minimise risk

Answer 1

Some of you should be using it as soon as you possibly can. The first version should be stripped-down, with only the most essential features that you need in order to use it as an (in this case) editor. Once you start using it you'll find out in a hurry which features are important.

Answer 2

You don't have to switch to using the development editor exclusively. Start using it until it impacts your production, make a list of the things that are problematic, fix them, repeat until you are able to productively use it most/all of the time.

Answer 3

Depending on how the development in being done you can switch earlier or later. If you are using a TDD methodology or where finding and fixing bugs is higher on the list I would start whenever you have enough features you feel would help your day to day life. This could be really early in the development if you have prioritized your features effectively.

Otherwise I would wait until you get to some of the later stages, pre alpha or pre beta. This means that you are not feeling too much pain early in the development.

As mentioned by other, if you can change your development efforts to try to make the product usable earlier do it! I would recommend to have people start using the product in earnest as early as possible to help evaluate the various features and get your initial users emotionally attached to the product. A developer who cares will often put in that extra effort to make the project just that much better.

Answer 4

It's about finding what your "critical mass" of features are. If it's just a matter of bugs and not features, switch now. Fix your bugs. If you are going to need to do feature development before your tool becomes useful, finish those critical features, and then switch over.

And I sincerely hope you're not writing an editor! ;-)

Answer 5

I guess the correct answer is as soon as you can. Of course using a buggy version is going to slow you down at first but then you will perform the QA as you are developing so in the long run you will save time. I'll suggest that some of your team switch and not the whole team to prevent a big hold if there's a blocker in the application.

Answer 6

For a while during the project, using a buggy editor is going to slow the project down and will be counter productive.

Sounds like you have your answer. The time to switch is when your project isn't going to impede on productivity.

Answer 7

<rant>

don't produce dog food, then you don't have to eat dog food.

what is the origin of this sick and stupid phrase anyway? dogs don't produce their own food (with one vulgar exception)...

</rant>

ask the PM what is more important: using the product under development to do development, or producing quality code on time? if there's a conflict, which is more important?

the common-sense answer is: use the thing you are building when it is better than the tools you have.

Answer 8

This is one of those "it depends" questions. Some guidance:

• What are the risks of using the project before it's fully baked? Are they acceptable?
• Will the project progress faster or slower, and is this an issue?
• Will the quality of the end product improve from a business point of view?
• Will you end up with features that make the programmers more productive but aren't useful to the customers?
• Conversely, will critical features be deferred because the developers aren't "interested" in them?
• Will the "taste of the dog food" motivate your developers?

Perhaps the most helpful guide is what I call "Headrick's Rule," after the coworker who first explained it to me:

If you need someone to accomplish something, make it painful for him not to accomplish it!

The flip side, of course, is to make it pleasurable to get the project done as quickly and as well as possible. Personally, I enjoy building and using tools, so I'd serve the dog food as quickly as prudence permits. But my coworker was a sadist and would have answered, "as soon as it compiles!"

Good luck with your project!

Answer 9

When the dog food becomes appetizing AND as soon as possible. I guess this is another way of saying that you should deliver value early and often. And, by the way, never deliver known buggy software. Fewer features without bugs is better than more features with bugs.

Answer 10

its all about size, scalability and scope. If the product would provide valuable success from the "dog food" approach then ASAP would be the correct answer. The end user experience dictates the end result of using the product.

Answer 11

Don't start using it until it reaches an "Alpha" stage. It should have all primary features complete and no known critical bugs. Then you can start using it.

It's also important to have the target users try it out, not just developers (unless it is a developer tool).

You want to have enough development time left to fit in as many "Wouldn't it be great if it did this?" features as possible.

Answer 12

The question is meaningless when applied to software the development team won't use itself, so the developers should use it as soon as feasible. "Feasible" means that it will work reasonably well, and won't break things too badly.

When developing a text editor, the developers should use it early, since mistakes aren't going to be crucial. When developing a version control system, the developers should use it only once it's been shown to be sound. It was something of a big deal when the Subversion team switched away from their CVS servers.

One idea would be to have earlier and later adopters among the team, as the later adopters are likely to spot things the earlier ones have become blind to.