The idea that as a developer, you should use your own products on a daily basis, even during development. This exposes you to all the weaknesses and flaws of the product, and makes you much better equipped to deliver a product that’s actually worth using.
But perhaps there’s a counter-argument that people seem to miss. If you use a lousy piece of software on a daily basis, you get used to it. You stop thinking about how it should be, and only consider how it is.
I’ve become less enthused about dogfooding over the years. At Real Software, doing as much of our work as possible in REALbasic seemed like a good idea, since it would give us all deep familiarity with our own product. In practice, though, the problems we faced while working on RB itself only sometimes resembled those our customers worried about. We were a small team with limited resources, and improving our efficiency was critical: so there was a constant temptation to prioritize the changes that we needed over the ones that would help our customers.
During my stint at Microsoft’s dev tools division, which has a long-established practice of dog-fooding, I met many people who were hired out of college and had never worked anywhere else. People referred to non-Microsoft tools and developer communities in ways that suggested they were foreign and little-understood. We collectively wasted countless hours dealing with buggy version control systems, antiquated test harnesses, byzantine scripting languages, unstable beta editors, endless system reinstalls, and the like, but the dogfooding policy was never questioned. I couldn’t stand it, but I think most people there were just used to it. They had learned each quirk one at a time, over years, and had developed work habits that insulated them from the pain.
Dogfooding may have short-term QA benefits, but it’s not worth the long-term cost. Productivity depends on concentration, and an unstable dev environment constantly knocks you off balance. The less frequently I have to stop thinking about my work and deal with some quirk of the toolset, the deeper I can get into the flow-state where the real work happens. Distract me too often and I simply won’t get anything done.
You make great points and I think you are probably right about developers developing developer tools.
At Google we do a lot of dogfooding, but I think it works better, because for each service, the vast majority of the dogfooders are not developers on that service. For example, everyone at Google uses the internal, not-yet-released features in Gmail, though only a small fraction of Google employees work on Gmail. The rest of us are much more like real users than the Gmail developers – although arguably email usage patterns within Google represent a very warped sample of email usage outside Google.
I’m sure the same was true at Microsoft – weren’t you using not-yet-released versions of Office and Windows?
Comment by Gretta — January 21, 2010 @ 7:04 pm
You do make excellent points, but I remember what it was like before RS starting using RB to write RB. There were easy, obvious bugs that were (seemingly) ignored because they weren’t painful enough to anyone at RS to get them fixed in a reasonable manner. Amazingly enough, when RS started eating their own dog food, the little things that drove us users bonkers got fixed because it also drove you guys bonkers.
Now, with that said, I don’t see how you can’t eat your own dog food. It makes too much sense from a testing and usability standpoint. A developer that sees a bug in their own product will, at the very least, fill out a bug report or send an email to the developer responsible. You may not if you’re not using your own product.
Sometimes I think RS would be better served with creating a very small (
Comment by Bob Keeney — January 22, 2010 @ 8:20 am
To me, dog fooding makes sense in certain contexts, but not all. Go figure, a blanket arrangement doesn’t work for all scenarios. ;-) I think that there needs to be a certain amount of dog fooding within a company so that they stay in touch with the products they provide to the end user. Without that, it becomes too easy to get out of sync with what’s really needed. But that being said, I don’t think the dev staff is the place to do the dogfooding. Developers need as few distractions as possible because their jobs require intense amounts of concentration. If your bleeding-edge product is used for dogfood, then it can actually harm the company far more than help it. I felt this happened at RS frequently. Many features of the product arrived not because they were best for the customers, but because they were best for the engineering staff. Applying those resources towards the customer would have served a far greater purpose. The problem was: outside of the dev staff, there really were no other people would could dogfood the product, so who should have been the guinea pig for any sort of realistic dogfooding?
Comment by Aaron Ballman — January 22, 2010 @ 10:54 am
Looks like the rest of my comment got cut off. :)
If you had a small consulting team that did projects, I’d make them responsible for making examples, updating documentation, answering forum and NUG questions, and testing when they weren’t busy doing projects. If you don’t want the product developers using the product then you need a group that is intimately involved in day-to-day usage. I think one experienced developer with a couple of college newbies could do wonders….
Comment by Bob Keeney — January 22, 2010 @ 3:57 pm