Dogfooding is using your own software while it is being developed. Sometimes it is impossible to simple use it at all (e.g. software for fighter pilots.) More often it is possible to dogfood, but it doesn't happen anyway.
A couple of "Our users won't experience that problem so it can't be a dogfooding bug," and quickly the practicalities of dogfooding go down so far no one does it.
What are the best practices about getting dogfooding to actually happen?
It's cheaper than employing testers?
(We need an irony smiley)
An advantage of dogfooding is it allows you to make mistakes when using the software.
The problem with testing by developers is that they know which button to press and so never press the wrong one, so that code path doesn't get tested. By using it day-day you are more likely to make the same mistakes your users willl make.
We spent [Insert cost] dollars and took [insert man-months] months to make that software, and by [Insert preferred Deity], we are going to use it!
Surely it depends on what your software is? For instance, I write software that I need for a particular time, and then continue to reuse in other projects. Hence, I do actually eat my own dogfood because I created it to serve my needs (and as it happens, others use it also because it works for them and they think like I do).
But as you rightly say, for some commercial enterprises, it's not possible because the employees of the company are not the target audience of the software being developed. In this case, you would need to be really proficient at testing your software, and also have loads of unit-tests to backup the stability of your software.
I would say that the best motivator is to create a mapping between quality software and everyone's personal quality of life.
Concrete example: the customers for our large scale sensor processing system are both internal and external to our department. The people in my group feel the "dogfood factor" strongly in several different ways:
My feeling is that, if you and your group don't actively see the relationship between the system's quality and their own quality of life, you're detecting a fairly high screwed factor.
PS: some time later, we lived a concrete example of this.
In January, we were asked to support our customer on site for the entire month of February. When we arrived, we were presented with a short list of critical issues: "these have to be addressed by March or the system will be considered unusable for our efforts in May."
At the end of February, we heard "the deadline is now the end of February." (!)
If we hadn't been living the system, all of us using significantly harder than our customers during that timeframe, working all the details as hard as we could in the lab, we would have been in something of a tight spot. As it was, I was able to say "okay, we were in final wrap-up testing. If you are willing to accept it as is, it's a solid product and we're ready to ship right now."
The moral of the story is that we made the best dogfood we could make. We took a known release, we updated it, we'd lived with it, working with real data, looking for serious problems and documenting the non-critical issues. At this point, our customer is completely taken aback, our management is ecstatic and I'm declaring victory.
Dogfooding only works when you depend on the software for a critical business process. If you don't then forget about it.
Another way of dogfooding developers is to let them spend a few hours on the support line and let them deal with the clients issues. This can be a good incentive to improve the user experience
One best practice is to tag bugs that prevent dogfooding (in any way) as 'dogfood' bugs. Bugs tagged this way are considered one step below breaking the build.
A couple of "Our users won't experience that problem so it can't be a dogfooding bug," and quickly the practicalities of dogfooding go down so far no one does it.
If it bothers you, you should fix it. IMHO, that should be the mantra for every programmer on every team of every size, everywhere. Even if it is a problem that you can guarantee will never affect end-users.
I have a sister who paints. Painting, in spite of what certain LISP programmers will tell you, is almost entirely unlike programming. However, there's one little similarity in process, a similarity common in thousands of crafts: attention to detail divides the good from the bad. My sister might paint something in an afternoon that looks... ok. At first glance. But without the next week or month of attention, of critical examination in different lighting, of tweaking and re-painting, the piece will never be more than a rough hint at what was intended.
You might throw together a rough UI, a passable algorithm, based on reasonable specs, and think that QA can hash out any problems on their own, or that user feedback will tell you all you need to know... but until you've spent days using it yourself, feeling the rough edges, you'll never appreciate potential improvements, or understand the poorly-expressed discomfort of your users.
You, the programmer, are the Super User. You are the only one who can both experience a problem, communicate a solution, and implement the correct. End users can experience, QA can communicate, but only you are in the position to do all three. Therefore it is vital that you are allowed to do so.
We develop an IDE, and it would be a shame to not use it to develop itself!
Not referring to the product of the team's labor as "dogfood" would probably help.
I guess that it depends on the software you write. For in house software, which is what I've been doing in the last years, I've noticed that after some resistance, people now don't have any problems with participating and using beta software. I believe that the most difficult part for them is seeing that thei opinions are important. After seeing that we do value their opinions and that we try hard for making their app solve their problems in an easy way, they end up liking it and are eager to participate on future projects.
A best practice is to 'stage' disruptive changes. There are two ways to do this. One is statically with a branch in source control. In that case the disuptive change comes in all at once when it is dogfood ready. The other is to dynamically stage it. This means allow the change to be turned off by dogfooing users while it is still being developed. This second option involves coding up such a staging mechanism, and then tearing it down when complete. This is a best practice for dogfooding, but the extra work can (in my opinion usually wrongly) be argued as a negative from a business perspectice.
There is only one way to get this type of thing to happen: Upper management MUST be behind it.
If you can't get Upper management to mandate it, then it won't last.