Hacker News Reader

Comment by typetypetype | Hacker News Reader

> We were all using the product so when there was funny stuff we tended to catch it.

I love this. There have been so many times I've run into a bug that makes me wonder if anyone on the engineering team actually used the product.

View on HN

Also known as 'dogfooding' or 'eating your own dog food' [0], and yes, not enough companies/software teams do this. Developers that build software aimed at or naturally used by other software developers kind of have an unfair advantage here.

https://en.wikipedia.org/wiki/Eating_your_own_dog_food

The company I work for, and specifically the product I support, came out with modular "apps" that can be installed to enhance the functionality. This came out about a year ago, and while the number of apps is pretty impressive for the niche market the product falls into, none of the apps were terribly useful or complicated. There wasn't a huge incentive to actually care about the app market, let alone download and use any of them.

So leadership made the decision to dogfood our own app environment. Any new features that are not part of the core experience or modifications to existing features are now apps. And guess what? We found some limitations to our app infrastructure, corrected them, and now we have a (again, relative) ton of high quality apps. Turns out no one was making apps because the experience sucked, until the developers found that out first hand and course-corrected.

Back when I worked for a pre internet messaging company our terminals speed was slowed down to the same (1200 or 2400 baud) as a dial up user would see.

There was a story last year about Facebook having "2G Tuesdays" to give employees an idea of what life on a slow network is like. I wonder whether it caught on?

Such a genius idea. I see far too many web applications not caring about latency. Forcing a developer to experience the same pain should help them. Unless that simply becomes the day everyone typically takes off, blames productivity on slow network connectivity, etc.

Google had a latency proxy on the corp network that you could use to simulate dialup, 2G, DSL, etc (along with unreliable connections). It was a great tool, and you could learn a lot by doing all your normal searches through the latency proxy. Alas, not many developers knew about it, and even fewer were willing to take the convenience hit to use it as part of their normal experience.

There is one built into Chrome now.

https://developers.google.com/web/tools/chrome-devtools/prof...

OS X used to have a "Network Link Conditioner" that shipped with XCode, I believe. It did a lot of the things you're suggesting, but right at the network interface level. Unfortunately, it broke with the advent of Mavericks. No idea whether it works now, or even still exists.

On the last web-app project I worked on, we had a middleware that activated automatically in dev mode and just inserted a delay in every request to bring a local delay up to our users' median delay. It was intentionally a bit of a pain to turn off, so almost everyone ran in that mode.

Still exists. https://developer.apple.com/download/more/?q=Hardware%20IO%2... is the link you're looking for.

Dropbox is one of these - not necessarily latency but bandwidth. If LAN sync fails it quickly falls back on uploading/downloading files via Dropbox's servers, which can be expensive depending on what connection you're on. There's no way to debug why LAN sync isn't working and it doesn't seem to respect Windows 10's Metered Network settings.

In my experience dogfooding is the only way to build a great product. Without dogfooding features erode. The "oh I haven't tested that in 6 months" happens frequently. The UX never evolves. I have NEVER worked on a product that got worse when it was dogfooded and I have NEVER worked on a product that consistently got better without dogfooding (sometimes it'll get better but it's always in spurts before going back down again).

Dogfooding is so under utilized especially in big companies.

Dogfooding only helps here if the dev team's use cases match the users's. Just about every company I've worked at has "dogfooded" its products, but almost always a small subset or even a completely different configuration from a typical customer.

Dogfooding is difficult to achieve if you work in a niche industry which has no immediate relevance to your development team. Smart developers who care about what happens beyond the back of their monitor will, of course, quickly learn a lot about the sector, but they're never going to know or care as much as a real user of the product, and they're never really going to have the same interest as they would if they were building a text editor.

Dogfooding does not require interest. Yes something niche that a developer on their own will never use is difficult (I think we had this as some of the previous companies I have worked at). Still, you should get the development team to use and demo the system on a semi regular basis. Make creating project ideas or something that they can use your product to make and play with. Tell them to take off every X hours a week or two weeks or something to ensure they are constantly using the product.

It's harder but in my experience it's still necessary. At least I've never seen a good product come from a team that didn't also use the product. That I know of, anyway.

Dogfooding is quite important, yeah. Some products, hmm, maybe not. For example, if I work for a dating app, I may not feel comfortable actually using the app myself especially when I am committed to a relationship. I.e. I can't dogfood it because I have no use of the product. In the case of say Facebook, I believe employees use the site internally so dogfooding is possible, even if privately some employees don't actually have a Facebook account. Going extreme, people who are responsible for designing military jet or nuclear reactor, they can't dogfood any of that, only simulation and model testing are possible.

For low barrier to entry products like facebook, dating sites, etc, I think companies are smart enough to build internal facing development only environments - so as a developer you won't be "using" the dating site, just using/testing/dogfooding the internal "dev" dating site that has maybe a million robots and all the employees, contractors, partners of the company.

If you haven't set down ground rules with a partner for working at a place like that, it's not a technical issue re: dogfooding, but a communication issue with your partner.

For things like military jets, nuclear reactors and the like, many times companies hire ex-military jet pilots (test pilots like for example Chuck Yeager), and former nuclear power plant operators, or even university profs who developed/calculated the nuclear fission equations in the first place (ie Manhattan Projected hired basically all nuclear physicists in all universities in the US for the effort) - they also do "testing" - which could be a form of dogfooding.

That isn't the same thing as Dog-fooding by the way.

Right, building a stage site internally or asking a pilot to test are basically user acceptance testing. Xeros builds a new printer model, replaces all the printing machines on the first floor that's dogfooding. But I get what you are trying to say.

Half the [low priority] bugs I fix are because they get too annoying while developing.

I somewhat blame this on the emphasis that now gets placed on automated testing (to the extent that nobody actually pronounces the "automated"). It's got some good points, but if it comes at the expense of manual testing I'm not convinced that's always a great trade-off, especially for interactive software.

I don't think conflating dogfooding with manual testing really works - they are different actions and you can have a dogfood culture without manual testing, or vice versa.

If you're talking about manual testing in the sense of "run down a long checklist", yeah that's different and automated tests are a better (although still not perfect) substitute for that kind of thing. But definitely still consider dogfooding to fall under "manual testing."

I don't think it fits under that at all, and I find that when people do see it that way it gets an entirely different treatment. "Manual testing" is an activity you do when you are thinking about how the product works. "Dogfooding" is a culture of using the product in order to achieve other tasks that you really wanted to get done.

I worked at a iphone game company, where after about 6-9 months of of them being there we let a game designer go. Of course we recycle the ipads to the next person, at which point we realize, none of the hardware had been authorized to run our app so therefore could never have been played. Yea....dogfooding is important

Reply on news.ycombinator.com