7 ms·

The dangers of eating dogfood

33 points by toast76 13y ago

greenyoda 13y ago
"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 13y ago
  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.
- hrktb 13y ago
  > 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 https://news.ycombinator.com/item?id=5601511
sandromorghen 13y ago
I totally agree with your article.
azio 13y ago
Good insight but exaggerated.
Falling3 13y ago
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 13y ago
  > 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 13y ago
    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 13y ago
      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.
    - geon 13y ago
      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.
usea 13y ago
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.
6ren 13y ago
"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 13y ago
"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.
logicallee 13y ago
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.
- OGC 13y ago
  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)
- konstruktor 13y ago
deleted 13y ago
[deleted]
drewcoo 13y ago
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 13y ago
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.

33 points by toast76 13y ago

"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 13y ago
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.
hrktb 13y ago
> 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 https://news.ycombinator.com/item?id=5601511

sandromorghen 13y ago

I totally agree with your article.

azio 13y ago

Good insight but exaggerated.

Falling3 13y ago

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 13y ago
> 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 13y ago
  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 13y ago
    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.
  - geon 13y ago
    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.

usea 13y ago

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.

6ren 13y ago

"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 13y ago

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

logicallee 13y ago

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.

OGC 13y ago
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)
konstruktor 13y ago

deleted 13y ago

[deleted]

drewcoo 13y ago

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 13y ago

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.