[didgetmaster]

'Eating your own dog food' is the best path to quality software in my opinion. Too many people working for a software company (developers, salespeople, product managers, etc.) never bother to use the software to do the kinds of things they expect their customers to use it for on a regular basis. Write the code. Make sure it passes some tests. Move on to the next project. This is common.

No wonder so many bugs never get reported unless many customers run into it much later. I have a project I work on regularly. I use it regularly to do productive things and I find most of the bugs just doing that. I had a couple different 'business partners' who talked a good game, but I could not get them to actually use the software and give me feedback on how to improve it. Neither one added much value to it and quickly moved on to other things.

[routerl]

> Write the code. Make sure it passes some tests. Move on to the next project.

Let's mention the missing step: don't even bother to run the code.

I'm simply embarrassed to admit how often I've been in teams that not only "don't use the software" (i.e. no dogfooding) but even "don't run the program". It's embarrassing. These types of teams miss bugs that get shipped because not one of the people involved in making that software has ever even actually run the damn app, let alone actually used it for any length of time.

This is shameful and embarrassing. Our profession is a joke. How can we even call ourselves professionals?

[lloydatkinson]

I agree with this so much. Only yesterday someone picked a ticket off the backlog to change a minor detail on a feature I've been working on. Rather than getting me to do it (a ten second job) this person made the change and also made unrelated changes. Now the user may proceed to the next step and bypass all the validation errors in fields they forgot to put values in.

If they'd ran it, they'd have seen how broken it is. But they didn't run it, and just merged the branch.

[baetylus]

Another underappreciated effect of dogfooding may be its reduction in bloated functionality.

If you're not dogfooding, you rely harder on a mental user model. Just conjecturing -- not only does that model diverge across your organization, but it could result in more top-down decisions about what a user wants, which probably creates more politics and friction all around your teams.

[DavidPiper]

An issue I've encountered is that all of those non-developer people you mentioned generally don't eat the dogfood, even if they push the idea of dogfooding themselves.

They assume (or don't even pause to think about it) that developers eating the dogfood is enough.

At larger companies, "eating your own dogfood" only works well if people with power to make roadmap and time-allocation decisions also eat it.

[userbinator]

Dogfooding was popularised by Microsoft, which AFAIK is still doing it, but it seems these days it's more like they're just being force-fed the dogfood without having any actual power to change it.

[routerl]

One of the main problems with Facebook's metaverse was precisely that none of the developers working on it actually wanted to use it, to the point where it had to be mandated by management.

Like, guys, when even the people who are making your product don't want to use it, this counts as data about how successful the product will be. If you have to force paid employees to use the product, then you'd have to pay users to use it too: there's no profit margin here, there's no user base.

[bee_rider]

Dogfooding is good, but I wonder to what extent it has become the case that problems that programmers have (solved by software that programmers will use and can easily evaluate how it works) are already solved pretty well by open source programs. I mean, imagine trying to sell a compiler. Good luck.

If you want to sell software, maybe one of the biggest markets to play in is software that programmers don’t find interesting to write and use?

There’s clearly not a 100% overlap between problems that programmers find interesting and open source projects. But it is applying not so favorable filter, right?

[recursivecaveat]

It's maybe no coincidence that some of the biggest companies that actually sell software (as opposed to user data) that I can think of are Epic, Salesforce, and Intuit. Imagine spending your evenings on volunteer work for a CRM system, bleh.

[eBombzor]

Sounds obvious in theory but the majority of applications are targeted for a very specific audience, i.e. banking, freight forwarding, CRM even. Not to mention if you work at a mid+ size company you'll be working on a piece of the application. Good luck trying to use that in your day to day life.

[eschneider]

If you're writing software to automate a business process, you're well advised to spend some time learning how to do the job you're automating so you some idea if what you're making is shit or not.

[euroderf]

Or you could just write ERP software, secure in the knowledge that the customer organisation will be bent to conform to the ERP model.