The Importance of Software Dogfooding

The term dogfooding, also known as to eat your own dogfood is basically to consume your own product. Use your own product as if you're one of the users, or in short: be your own user. The majority of people, not just in Indonesia, but mostly around the world don't want to use their own products, with various reasons. One reason that I've encountered the most is "I've seen enough of this at work, why would I want to see that thing (referring to the product) again outside work?".

I think, as a developer, instead of having feedbacks only from customers and internal team (like the business or marketing people), it's a good idea for us to also use it, as a customer. We might be one of the power users, because we understand how things work under the hood. We might also experience how it is to use our own product, is it enjoyable? Do we really having a hard time using it, like one of the customer's complaints? In the end, we'd know which part needs adjustment from the technical side, and which "bugs" can be turned into feature because it's actually helpful for our customers. It really forces developers to be on the customer's shoe, and it's a good thing.

Apart from having the thoughts of "I don't like having our company taking our salary to pay for their stuff!", and the company that we're working for is actually solving the problem we've encountered on our day to day basis, dogfooding can make us be a better developer, by creating better decisions. We can be much more vocal when having a discussion with product, business, or marketing people.

Enough with theories and rhetorical "good case scenario". Let's talk experience.

At the time of this writing, I worked at a stockbroker company. Having to eat my own dogfood meaning I have to buy a company stock from the Indonesian stock market. Perhaps if I were to test something out, I'd need to create a new trading account, put some money into the investment account, and go buy some stocks or participate on one of the IPO series. It requires somewhat a not-so-small amount of money, yet that's not necessarily the one you have to do when you're doing dogfooding on a stockbroker company. I can also do some things that doesn't require paying extra sum of money, like looking at the stock charts, watching the research team providing helpful information regarding the state of the market on every morning.. and so much more!

Another story that I have is through my open source project, called Pesto, that some of you might know. At its' early stage (for me, it's still early now), I don't know whether there are actual people using Pesto as their code execution engine. I don't really to create any tracking scripts or counter that measure the number of people using it. I just want to measure the performance of the Pesto code itself (and that is by using Sentry's performance feature). I only do "does this code works" by using an integration testing on the GitHub Actions workflow, I never really test it routinely on real-life. And so, I made a PR that initializes the way we do dogfooding as e2e testing. I also put the implementation of Pesto using the Pesto's Javascript SDK (that I also made) to the Teknologi Umum's Bot. Aside from being the user of my own product, I also want to see directly about how often do people use this (on some group that actually got the bot running) and is there any bug we can tackle?

There is one more experience on Sentry self-hosted repo, that would probably make this post long and boring. That should be covered on another story with another topic.

Alas, how everything turns out forces me to be a better developer (I think), by refactoring and improving the code I deemed slow, buggy, problematic, or missing something here and there. Refactoring itself is not really a scary thing to handle. Besides, every software is always a work in progress.