The dangers of eating dogfood | Hacker News Reader

The dangers of eating dogfood

blog.downie.com.au

33 pointstoast7618 comments

"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.

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.

> documentation

There was a submission a while ago [1] about why you'd just read the code is documentation is not good enough or simply inexistant. When working with your company's product you often have direct access to the source code or the developers, and you can solve in minutes problems that would cause days and days of pone/email back and forth with the support team.

You'll understand there is a problem, but you may not have the same sense of urgency since it was so fast to solve.

[1] https://news.ycombinator.com/item?id=5601511

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.

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.

Regarding 3):

They _really_ should. I have a feeling they dont use it at all for actual task (except for testing out if something works)

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.

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.

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.

> 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.

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.

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.

You are missing the point. You as the developer can -and will- change any detail you don't like. The customer is helpless in your hands.

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!)

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.

  "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.

"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.

I totally agree with your article.

Reply on news.ycombinator.com