
The dangers of eating dogfood - toast76
http://blog.downie.com.au/the-dangers-of-eating-dogfood
======
greenyoda
_"Dog fooding makes you lazy, and makes you less likely to understand your
customer."_

I don't understand how dog fooding makes you lazy. Using your own products
doesn't stop you from talking to your customers. If the company leadership
cares about what the customers think, then someone will find the time to talk
with them.

And using your own products has many advantages, such as forcing you to
confront bugs and annoying user interfaces and performance problems and poor
documentation. It's definitely something that you should do, assuming your
products can serve some useful function in your company.

 _"you never have to find the documentation, or learn how to use your API."_

Documentation is an issue you'll face even with your own products. Unless your
company is very tiny, there will be employees, even developers, who aren't
intimately familiar with how to use all the advanced features of your products
to solve real-world problems.

~~~
pinaceae
fully agree. dogfooding makes especially a lot of sense if your company has
more than one product. my team, which is working on a commercial app, just
started using the rDMS built by our second team - and it's great as we act as
beta tester _before_ our customers get it into their hands.

this is not about classic QA, this is about "design bugs", that one extra
annoying step in a workflow or missing safety dialog that doesn't warn you of
a irreversible change.

of course this works particularly well as that product fits into our workflow.
dogfooding becomes a bit unrealistic once it is about a product only your
customers will really _use_.

------
usea
I think this article makes a good point, but the way it's worded makes it easy
to disagree with. Using your own product is better than nothing, but alone
it's not enough to understand the relationship customers will have with it.

Dog food is not dangerous, you just have to include other foods in your diet
to complement it.

------
logicallee
The points are good, but missing the elephant in the room: when you are
competing with the best companies in the world in software (where the marginal
cost is 0), you simply can't afford to compete using anything less than the
best stuff. You need to go 'deep' (specialist), rather than 'wide' (mass-
market) when it comes to the tools you yourself use. (Even though what you're
creating is probably itself wide.)

That's why Microsoft doesn't use it's own source control solution (SourceSafe)
internally. It just doesn't cut it.

That's why Apple doesn't design the next iPad on an iPad.

That's why McDonald's executes don't hold their business meetings in a
McDonald's, to close important international deals etc.

You just can't afford to. This guy says "At BugHerd, we build a project
management tool for web projects. BugHerd is, itself, a web project."

Imagine you just wrote the first version, and you realize that it sucks. How
will you track the transition to the second, non-sucky version? If you're
using project management software - the one you've just written - that by your
own admission sucks?

That is a formula for disaster.

But the very same argument (for not using a disastrous tool) applies for the
continual marginal improvement that better tools can give you.

It makes ZERO sense to 'bootstrap' any tool using that tool except for some
special exceptions.

That doesn't mean you shouldn't test it :)

\--------

Some exceptions:

1) The tool is the only one that exists. Even a buggy version that takes 10x
longer to produce a halfway decent result would still be the only thing that
exists.

Perhaps the first compiler was like this: i.e. the first time someone
translated paper into a compiler, it made sense to use that buggy version to
recompile itself with optimizations. But that's because it was the only one to
exist.

2) if you are now the best on the market, period. So, if you so happened to
create the best tool on the market, sure, go ahead and use it.

3) if you are on par with the best. This is tricky. You can learn a lot from
the competition. It hink in this case you should use both. Gimp might be 'on
par' wtih photoshop, but I really think that Gimp developers should use both
on a daily basis. It's amazing what kind of a perspective access to being an
occasional user of your competition gives you.

~~~
konstruktor
I almost quit a job after having to work out a solution to a real-world
problem dogfooding a product that was, at that time, really shitty. The
problems with that version were known and the roadmap for the next one fixed,
so no value was added except that some manager could boast about dogfooding.
However, my mood was very, very dark during that time and quite some time
after that. In hindsight, I should have just quit, and I would in a similar
situation in the future.

I thus consider all dogfooding unethical that is not done by somebody who has,
or is provided with, a lot of influence on the product.

~~~
logicallee
You bring up a good political point actually, glad you brought it up.

Apple doesn't use it's most mass-market product, the iPad, to develop the next
iPad. But it does use Macs, probably even where they're slightly worse than
PC's. If some kind of developer at Apple really needs a Laptop with 64 GB of
RAM they probably can't get away with it without a very good justification.

This does, however, have objective benefits as far as company image, esprit de
corps, promotion, etc.

But Apple might be a special case.

I guess it comes down to whether you're building just a tool or a lifestyle
image.

If you're building a lifestyle product, then sure homogeneity or self-
promotion has a huge objective value to the company.

------
Falling3
And that's why you only buy human-grade dog food if you care about your dog.
(Yes, I read the article)

I disagree with the article and think this is one of the best ways of actually
understanding your product and how well it works in the real world. Don't test
it like a developer. Use it like a consumer.

~~~
geon
> Use it like a consumer.

I think the point of the article was that that is impossible. Your real
consumers have issues you yourself simply cannot have. Whenever something
about the product is bugging you, you fix it. The customer is depending on you
for everything.

~~~
Falling3
And I simply disagree with that. Don't test it out. _Use_ it. Take the
canonical to-do app. Don't create a list and just test out your features.
Integrate it into your life. Use it for your home improvement projects and
your shopping list. There is absolutely no reason you can't depend on it the
same way your customers do.

~~~
dragontamer
If you are a startup writing time-reporting systems, you will never be able to
use it like the big customers. No startup will ever need time-reporting system
consisting of thousands of charge numbers. No startup needs to worry about
government compliance of charge numbers, or tax codes across all 50 States.

Hell, you probably don't even have 50 employees, let alone a reason to have
all 50 tax codes in your time charging system.

------
drewcoo
Insipid.

Myopic view of your product? Then also use competing products to see what they
do. And talk to customers. A lot. Golly, understanding that all of your
customers aren't you seems like it's not a huge leap.

Figuring out pricing models? Well, I'm just a dumb engineer so I assume
someone else knows about that but I'd guess that "not free" is a good starting
point and you can probably haggle and talk with people from there.

I would hazard a guess that everyone wants a better bug tracker/project
manager/et al. I would also hazard a guess that what everyone wants is a
totally different thing than what everyone else wants. We've had these
technical "solutions" for decades now and they all suck.

They suck because the actual problems aren't technical. They're people
problems. How should you track all tghe whatzits in a way that makes everyone
happy enough to work effectively but also accountable? That's an ape problem
and not a technical one. The solution is in ape-space and not tech-space. Look
to Skinner and not Knuth for those answers. (And please don't look to Skinner
- creepy!)

------
mnicole
By the last paragraph, I get what he's saying (too many companies build
something they'd never pay for in hopes that there's an audience that will),
but I think he's arguing two different - but vital - aspects of testing.

There's dogfooding and there's finding users at all levels of experience (both
in internet proficiency and experience with the type of software/service
you've built) who have little/no incentive to use your platform over the
competition. The best apps I have come across have had their community
managers leverage me and ask repeatedly for my feedback and how to make things
better. What else am I seeing going on in the market? How intuitive _is_ that
action? If this tool didn't exist tomorrow, where would I go and why? If a
user isn't willing to take the time to answer these questions, move on to the
next person.

Reaching out to the right people here means free advertising and loyalty, in
addition to fixing the problems you don't come across internally.

------
6ren

      "would we pay for this?".... and as a cash strapped startup we said no.
    

Thank you! I'd come to the same conclusion myself - it's reassuring to hear
someone else say it.

The important thing is to see from your customer's point of view. Dog-fooding
is just one technique that helps that. There's also: listen to them (and
facilitate that); imagine a day-in-the-life; work in their industry; visit
them; watch them using your product.

But remember that the rare and beautiful insight is of a problem they didn't
know they had.

------
frozenport
"using some small slice of functionality" Knowing when your code breaks is
invaluable and trumps any potential big picture problems. You can have the big
picture correct but it is worth nothing if your product doesn't exist because
your code doesn't work.

------
sandromorghen
I totally agree with your article.

