Dogfooding: See something, say something

See something, say something

There is a simple principle I adopt when dogfooding a product and filing bugs: See something, say something. If I see something that is off, I report a bug. Everything else is noise.

But bug reports need to be actionable and constructive. So, I am mindful of certain principles when dogfooding any product. I think of them as Reminders and Responsibilities.

Reminder: The bugs that I file via dogfooding will help improve product quality.
Reminder: The bugs I file will aid the product- or feature-team’s work.
Reminder: Bugs I report via dogfooding are just as valuable as the code that I write as a developer.
Reminder: The team’s opinion or reaction to the bug report is of limited relevance.
Responsibility: How the bug might be triaged (resolved, closed, assigned, etc.) should not factor into my decision to file bugs.
Responsibility: The issue details I offer in the bug report should be clear and actionable.
Responsibility: Reporting a known issue is no excuse to not file it again, if I have not already reported it.
Responsibility: Developers are not the only ones who file bugs.

Reminders give me permission and, dare I say it, courage to file bugs. Responsibilities ensure that the bugs I report can be useful to product team when improving quality.

But why am I talking about reminders and responsibilities when dogfooding? Or what is dogfooding? Let’s start from the beginning …

Dogfooding

Dogfooding is the part in software engineering when you consume your own work, code, or product as part of your regular, everyday routine, to see if everything works. And if something does not, you file a bug, open a ticket, and work to get that bug/issue/ticket resolved – in the spirit of improving product quality.

Dogfooding is a product team’s first line of defense against the obvious bugs and UX issues. The idea is simple: if you as the creator of the product cannot use it yourself without friction, how can you expect others to use it, esp. when they are less familiar with your creation.

I consider dogfooding to be *the* standard on manual software testing. It can be continuous when consuming your own product daily (you should). It is empathetic – puts creators in their users’ seat. It is illuminating – drives visibility around obvious issues, fast.

It is not without its faults. Makers tend to have biases and blindspots about the usability of their own work. So, when dogfooding becomes your _only_ way to test and assess the quality of your product, then it’s not a thorough evaluation of your work. But it is the first step towards evaluating the product in real world settings.

I can file bugs?

The bigger – perhaps the biggest – issue with Dogfooding is the peer pressure you must fend off when filing a bug on your colleagues’ work. It is a culture issue.

This takes many subtle shapes and forms, some of which I list below. I wrote these in first-person to clearly illustrate different themes that give dogfooders pause when reporting bugs.

“This must be a known issue.”
“It’s still under development.”
“It’s not my feature. I should stay in my lane.”
“Will the dev get mad if I file a bug?”
“This is not intuitive. But maybe I am wrong.”
“This workflow is too complex. I am likely not the target user for this.”
“I think I have already seen a bug filed for this.”
“I can file bugs?

This is not an exhaustive list. And to clarify, these are not verbatim comments from anyone. However, it is informed by first- and second-hand anecdotes that I have heard from folks in tech, over the last fifteen years, spanning three continents and countless companies. This is why I am writing about this stuff.

“So, any bugs?”

Such issues hearken the disengaged dynamics of my high school chemistry classroom when the teacher would ask, “So, any questions?”

No one would ask questions.

Some were not paying attention. Some were too shy or timid. Some wanted to ask, but did not care enough. And the one kid who would ask questions would be the bonafide nerd in the classroom – few liked that kid.

Getting team members to file bugs via dogfooding has a similar disengagement issue. It is like asking: “So, any bugs?”

Any team will have a mix of folks: some who are engaged and routinely dogfood and file bugs; others who are shy, timid, or unsure (all of those things) to report issues.

In a healthy team most folks dogfood the product/service and routinely report issues. Such teams have strong, open engineering cultures, where folks adopt growth mindsets and everyone is encouraged to speak up. This is true of many companies and organization. That is good.

But even a healthy team will have junior and newer members who may ramp up slowly to that culture. Look out for that.

Which brings me back to the reminders and responsibilities we might be mindful of as product dogfooders.

Reminders

The first two reminders – *bugs improve quality and aid the product team* – ought to be non-controversial. Too often, I have seen folks second guess the value of the act of reporting bugs – let alone the bugs they actually report. I have run into this trap as well. Bugs are important data points for product builders. They fuel quality. Bugs are good. When in doubt, err on the side of filing bugs.

The third reminder – *reporting bugs is just as valuable as coding* – may run into some controversy, but I will stand by it. Software engineering is more than writing code. Too often a developer’s role is sandboxed to their ability to crank out code. That is misguided. Writing code is a limited part of being a software engineer. Being able to understand why you are writing that code, what came before, where the product roadmap is going next is perhaps just as important if not more. Reporting useful, actionable bugs that drive up quality shows that you understand why the product exists, and how users might be using your work. That is just as important as your ability to code.

The fourth reminder, i.e., *product team’s take on a bug report*, is a good point of distraction worth avoid when reporting issues. First, it’s not useful to assume what a product team will think about your feedback. Second, product builders are people who have biases and blindspots. As such, they cannot foresee every point of friction that their software can run into. By filing an issue chances are that you might be challenging some of those biases – that is good.

Responsibilities

The last reminder (re:*product team’s take on a bug report*) feeds into my first responsibility as a bug reporter: even if I know that a bug might be closed or dismissed with little action, if I see an issue, I report the issue. I do not let any prior bug resolution patterns.

Sometimes teams are stretched thin. At times they may not care about every issue. But remember: priorities change. all. the. time. The same bug that gets ignored today, might see a flurry of activity tomorrow. So, if I as a user ran into an issue with the software product: I must file that issue, irrespective of how it will be received.

My second responsibility as a bug reporter is to file reports with a clear description of what I expected as a user, and what actually happened; ideally with supporting data such as: steps to reproduce the issue, system logs, screenshots, screen recordings. This goes towards making the bug report actionable.

“That is a known issue,” is a common response you will hear from developers. Hearing that reposes, or anticipating it should not dissuade you from reporting the issue. File that bug, at least once if you have run into it. It is useful to know how many users are running into a known issue.

Here’s why: I am never going to be in a position to fix all bugs (time is a precious resource). What’s more: not all bugs are created equal – some are simply not worth fixing.

Often, what helps evaluate the value (ergo, priority) of a bug fix, is the number of users running into the bug. There are many ways to assess how broad an issue is. If a sizable number of users are actively reporting an issue, it is a clear signal that such an issue deserves attention, and a fix.

The last responsibility I listed above was a recent lesson I picked up. Bugs are not the purview of developers alone. Product managers, designers, marketers, lawyers – it takes a village of many different skills and professions to write and fix code. Developers may produce the final work product, but they do so on the shoulders of so much other expertise. Encourage everyone in the product team (not just devs) to dogfood and file bugs. This should be a non-controversial take, but one that is worth repeating and evangelizing.

What’s your take on dogfooding? Do you enjoy it? How do you feel about reporting bugs? Does my take resonate with you? Am I completely wrong here? Or is your experience somewhere in between?

Leave a reply or comment, I would love to chat more!

– vkp