DEV Community

Cover image for Dogfooding: Why should you test your own products?
Mad Devs for Mad Devs

Posted on

Dogfooding: Why should you test your own products?

Dogfooding, eating your own dog’s food - this expression sounds strange. What connection does it have with IT? Do developers eat dog food?

Well, no. Dogfooding is not about eating dog food. This expression is used for a common practice in many companies including those that develop software.

Dogfooding, or eating your own dog food, means using one’s own product. Some history of the expression might help you to understand it better.

The term origin

One of the possible origins of the expression is from the president of Kal Kan Pet Food. He said at a meeting with stakeholders that he could eat his dog food.

While there were other options such as “icecreaming” (Microsoft), or “drinking your own champagne” (Pegasystems), nothing stuck. There were also such expressions as “the practice you preach”, or “you make your bed, you lie in it”. But dogfooding was new, crude, and something that stays in mind.

In 1988, Paul Maritz, a Microsoft manager, sent a test manager an email titled “Eating our own Dogfood” with a request to increase the internal use of the company’s product. They even named a server “dogfood” for the staff to use.

Since then, the expression has been used for the practice when a team uses the product they are working on.

Quality assurance: software testing life cycle<br>

Dogfooding and not supporting competitors are different things

Before we move on, we shall understand the difference between dogfooding and the policy of not supporting competitors. So, when a car dealer encourages its employees to use the cars of the brand they sell only, it is not dogfooding. Or if CocaCola forbids its employees drinking Pepsi in offices, it is also not dogfooding.

What is the difference then between dogfooding and forbidding the use of the products of competitors?

The difference is in the approach.

Dogfooding is when you use the product you are working on to see how it works, to test it. It doesn’t imply that you are forbidden to use the products of a different company or a different department.

You do it because you need to see how it works in a real-time application, to check whether there are any bugs, any functionalities that shall be fixed, or whatever.

So, the aim of dogfooding is to test the product and to demonstrate the company’s confidence in the things they do, not to forbid the use of other products.

Examples of dogfooding? There are plenty of them:

  • The Microsoft staff using Microsoft products;
  • Apple employees carrying their MacBooks around;
  • Zoom staff using Zoom for meetings;
  • Oracle developers use Oracle Linux to develop Oracle (it sounds weird, doesn’t it?);
  • Gmail was dogfood.
  • Facebook React feature is also a result of dogfooding;

Whenever a company turns their employees into their clients - it is dogfooding.

Why is Dogfooding needed and whether it is needed, indeed?

Dogfooding is needed, at least in software development. During product development, dogfooding performs the function of testing (to some extent) and helps to detect errors, inconsistencies, and bugs before the product is released. After the release, dogfooding serves to show the company’s confidence in the product they have created.

QA engineers - are they needed?

Dogfooding stages

Normally, dogfooding comes in different stages. While their number might differ depending on the approach and the company, the most common stages are the following:

  • A stable version of an app is developed and made available for testing;
  • New features are added to the app, and it is re-tested;
  • Interviews are performed to see whether the app works as expected;
  • The company prepares the app for public release.
  • This process ensures that the software is useful. Moreover, the testing stage starts before the software becomes available for official testing and then, for testing in beta mode.

Pros of Dogfooding

Dogfooding benefits are not only in identifying bugs. They go far beyond this function:

Dogfooding pushes an emphasis on privacy

If your company isn’t allowed to expose to the public what they are doing, testing by users frequently becomes unavailable. Dogfooding allows replacing it without compromising the company’s privacy. Your app is kept in a closed environment and still is tested properly - isn’t it great?

Reduces the costs needed to hire outsourcing testers

When it comes to testing, it is sometimes difficult to find proper testers for an app. Good testers aren’t cheap, and not all of them have enough technical knowledge to test all the apps.

So, by using dogfooding, you reduce costs for testers. However, even not this is the main benefit. If you are developing a highly technical product, testers might not be able to provide a proper service due to the lack of expertise. In such a case, the company’s employees are the best testers because they understand the technical side of the product.

Saves costs in the long run

Dogfooding allows to detect errors and bugs asap, frequently, it is done in the environment and by people who are working on the product. So, all the issues are eliminated asap. In the long term, it allows saving a lot of money that would be needed to track back the bugs that weren’t detected at early stages and fix them.

Develops the sense of the ownership

Being familiar with the product develops the sense of ownership by all the team members who have tested the product. It, in turn, increases their level of responsibility for the product.

Demonstrates the company’s confidence in the product

If employees use the product created by the company, it means (or should mean at least) that they trust the product and are confident in its quality and functionality.

Why do software bugs occur?

Cons of Dogfooding

While offering many benefits, dogfooding isn’t perfect. It comes with some drawbacks, especially if you don’t prepare everything properly.

So, the main cons of dogfooding are the following.

Choosing the wrong audience

If you have chosen the wrong audience who doesn’t understand the product’s purpose, you might get flooded with wrong feedback. It may even lead the development team in a completely wrong direction. In the end, it might lead to a disastrous outcome when the development team delivers a product that users will hate. So, choosing the audience for dogfooding is one of the crucial moments for the product’s success.

Too much knowledge about the product

Standing too close to something might prevent the person from seeing some major drawbacks or inconsistencies. The team knows every aspect of the app, and it makes them bad testers. They are developing an app as they see it. So, it is important to involve in dogfooding not only the team working on the product but other departments, too.

The team might be biased to the product

Of course, they are working on it, it is their creation. It is not surprising that some emotional component will be always present when a specialist tests his own product. It is important to eliminate the effects of such bias. So, the product shall be tested not only by the development team but by employees from other departments and even managers and stakeholders - as long as they aren’t involved in the development process.

Dogfooding doesn’t replace testing or QA

Some people and even some specialists believe it does. However, it is absolutely incorrect. Dogfooding helps to detect bugs and so on, however, the testing and QA stages are indispensable if you want to develop a quality product.

Some scenarios might be overlooked

Usually, a user passes through one time through a scenario only. For example, a signup process - how many times do you sign up for a product or service? We bet it happens once only. However, if you do it once successfully, it doesn’t mean that thousands or millions of users who are going to repeat the process will manage it as flawlessly as you did.

Delays product releases

If you introduce the dogfooding phase into every stage of the development process, it will delay the product releases.

Not invented here syndrome

If a product copies something already available in the market, the team might get the so-called Non-Invented-Here-Syndrome. In most cases, it results in the product developed, dogfooded, released, and then, dropped. It doesn’t influence the team morale positively.

Do we use Dogfooding at Mad Devs?

We encourage our specialists to use the products they are developing. In most cases, our specialists are also the first users of the product we are working on. However, we understand all the drawbacks of dogfooding and do our best to prevent them.

We don’t abuse dogfooding. It helps our specialists to perceive the solutions from a fresh perspective.
We never replace testing and QA with dogfooding. These processes are different, and we do not mix them up.
We involve not only the development team in dogfooding but also specialists from other departments, managers, and stakeholders.

Dogfooding is highly beneficial if conducted smartly. We understand it, that’s why we do our best to organize it properly and get all the benefits it offers.

image


Previously published at maddevs.io/blog.

Top comments (0)