Eat Your Alpo: Dogfooding Is Good for Your Users, and for You

At New Relic, we say we “drink our own champagne.”* This is the equivalent of eating our dog food, but with a twist: we don’t just use our software to say we use it, we use our software to develop and enhance future versions of our product. Think of this as another tool in your engineering tool belt.

Cheers

Cheers to you, from us.

The dog-fooding concept is not new for the tech industry. In fact, it has been around since the early consumer computers were invented. Maybe it was used to create empathy for the end users, or possibly the quality control team needed some extra eyes looking at stuff. Dogfooding brings a new level of insight into the development of a product, from usability, which affects the customer experience, to prototyping, which can add quality improvements to a product before it is released.

Dog Champagne

Chow down, little guy, you earned it.

Microsoft used dogfooding during their Windows NT project. Novell, HP and Apple have also used similar tactics during product development with positive results. Many companies do it because the rewards are tremendous, valuable, and come at little cost to the company using it. However, not all dog food experiments end well. Take AOL-Time Warner, who enforced the use of AOL Mail on their employees. This endeavor ended poorly and resulted in lost emails and worker productivity. It was eventually discontinued. Why AOL-Time Warner didn’t use that lesson as a reason to redefine the product is anyone’s guess.

Usability is only one aspect of dogfooding. Another aspect is innovation. Before the Internet existed, a free thinker named Plato was (probably) quoted for saying “necessity is the mother of invention”.

My favorite example of innovation by necessity is from Netflix. They created Chaos Monkey to help determine weakness in their application environment by killing services at random. In doing so, they learned how to make their system more robust and able to deal with dependency issues more gracefully.

Respect the monkey

Respect the monkey.

Meanwhile, back at New Relic HQ, necessity also drives us to create what we need in our software. It may not come as a surprise that at New Relic, we use New Relic to monitor New Relic (at the risk of being trapped in an Inception-like limbo).

I myself am quality engineer here, and people often ask me about real-world uses for New Relic. Our own use of different tools in difference engineering departments is a great example of how it’s purpose can vary across teams:

    • Our Core Application team uses Transaction Traces for new feature development and legacy feature improvements on our code.
    • Our DevOps team utilizes one of our new products, Plugins, to help monitor the performance of our load balancers and databases. They also monitor the uptime and performance metrics for our Production and Staging environments using Server Monitoring, Alerts and the Deployment dashboard.
    • Our Performance team looks at our Core Application’s Apdex to look for any disconcerting trends related to our customers’ site experience and satisfaction.
    • Our Quality Engineers utilize our Errors dashboard to help detect stack traces, crashes and really bad things that might happen behind the scenes that most people wouldn’t even see.
    • Our newly formed Mobile teams use another of our newer products, Mobile Apps Monitoring, to constantly monitor and improve both the mobile apps performance monitoring agent and our New Relic iOS App.
New Reilc Coder

An actual New Relic coder using New Relic. Not a model.

One New Relic story I often share is about our recent move to daily production deployments. A few years ago we manually deployed twice a week to Production. During these scheduled deployments, we would gather around our chat client and the New Relic app, eyeballs glued to the New Relic charts and graphs to make sure all the deployment moments went smoothly.

Every week we would review our performance and fine-tune the slow bits to improve our system’s inadequacies and bottlenecks. From reviewing this data over time, we could confidently choose the right solution for the next phase of our production environment to prepare New Relic for the future. We now automatically deploy multiple times a day.

Yay memes

BOO YEAH!!

The New Relic dog food list goes on. The design team, security team, technical support, agent teams, VPs, and CEO still look at New Relic everyday to see what is happening on our site. We’re proud of what we’ve made and continue to improve on it every day.

Plus, we’re always hiring. Come join us in the fun!

____________________________________________________________
*To give credit where credit is due, I first heard “drink our own champagne” in a meeting with Brent Miller, one of New Relic’s senior developers. He didn’t coin the term, but its use perfectly complements how we use and create our software at New Relic. His blog postings can be found here.

kurt@newrelic.com'

View posts by .

Interested in writing for New Relic Blog? Send us a pitch!