Partager via

Why Dogfood?

  • Article

What is Dogfooding?

Dogfooding is a Microsoft term for adopting a Microsoft product (or in a generic sense any new technology) typically while the product is still in a state of development. Microsoft Product Teams provide release builds for consumption prior to the final release to manufacturing (RTM), and product teams typically call these pre-RTM builds betas or RC candidates. Therefore, internal Microsoft teams or Microsoft customers who adopt MS betas or RC candidates products are performing real dogfooding.

The balancing game that plays out during the dogfooding process is among the value gained from adopting the new product, the superior feedback to the product team during the adoption process and the increase in trouble or pain experienced by the adoption team because the quality of the product is not yet ready for production use. Typically the pain decreases as the product quality increases when the product moves from betas to RC candidates and culminates with the RTM release.

So what’s the big deal?

At Microsoft.com, Engineering runs systems under heavy load due to the large demand by the Microsoft customer base. The infrastructure to run these systems is ripe for real world testing, for those product technologies required to run the systems. Product teams with technologies that align to the MSCom infrastructure salivate when they watch MSCom Engineering dogfood their new product under this type of test conditions because they know that they can never create these conditions in an isolated lab environment.

As an internal adopter of new Microsoft product technology Microsoft.com plays a very important role in the successful release of the product by providing critical feedback to the product team on the quality and usability of the product in real world scenarios. When we understand our role properly, we build direct relationships with the product teams to provide this feedback while the dogfooding is in progress.

The end result is that Microsoft.com is finding bugs before you do. The reward we get is the ability to showcase new technology to the Microsoft customer community in a real world scenario.

So do you just throw the product out there to see what happens?

Ultimately, that is precisely what we do. However, MSCom Engineering performs a large body of preparation work before we get to the actual first deployment to production. Engineering organizes this preparation work by phases and conducts these phases in chronological order. These are the adoption phases, starting with as much lead time as possible:

Technical Planning

During this initial phase Engineering identifies gaps in existing technology that reduces performance, hinders productivity, or otherwise prevents operations from performing work. Then Engineering researches the feature set of the new product and determines if any new features close any gaps. If Engineering identifies any features which will benefit operations they become candidates for shared goals for adoption. An example of a shared goal is the SQL Server Mirroring technology which officially shipped with SQL Server 2005 SP1. Microsoft.com realized that Mirroring technology filled a huge gap in our availability strategy when failures occurred on SQL hardware.

Incubation

During the Incubation phase, Engineering exploits the new features identified during the Technical Planning phase which has become shared goals. This exploitation typically occurs in a controlled lab environment where the Engineer determines how the feature actually works and makes an assessment of its potential for production use. Using the Mirroring shared goal as an example, Microsoft.com engineers validated the feature and configuration in a lab environment during this phase and determined which production scenarios to best exploit it. This work coincided with the pre-beta release of SQL Server 2005 SP1.

Evaluation

During the Evaluation phase, Engineering deploys the product on production infrastructure and determines if the shared goals can be realized. Engineering works with the product team and other internal teams to remove blocking issues (bugs or other obstacles) that impede progress. Preparation for full scale deployment begins during this phase. The realized goals become the focal point for understanding how the full scale production deployment will proceed. Using the Mirroring shared goal as an example, Microsoft.com engineers deployed SQL Server 2005 SP1 to four different production situations and validated the feature, providing critical feedback to the SQL Server team. This work coincide with the beta and RC candidate releases of SQL Server 2005 and thus the feedback was timely.

Deployment

During the Deployment phase, Microsoft.com engineers deploy the new product technology to all production scenarios where applicable, working with internal application development teams to insure that the deployment does not interfere with the availability and reliability of the applications depending on it.

You want some?

Early adoption of new production technology is not a scary world if you approach it with a level head and a plan. The rewards outgains the risk and pain if you can find how to exploit the technology for the benefit of your business, otherwise it will feel like you are stranded up the creek without a paddle.

Comments