Microsoft's dog food diet
Published: 17 Jul 2003 10:32 BST
Microsoft's technology dietitians offer employees only one item on the menu: dog food.
That's because the software maker has a philosophy known internally as "eating our own dog food", referring to the common practice of running beta, or test, software throughout the organisation.
The whole dog food concept has never been more important to Microsoft or potentially difficult. The company now has more enterprise software testing at one time than perhaps any other time in its history. Testing products include Exchange Server 2003, Office 2003 and Real-Time Communications Server, SharePoint Portal Server 2003 and Windows Messenger 5, among others.
ZDNet UK's sister site CNET News.com spoke with Rick Devenuti, Microsoft's chief information officer, about the practice and how it affects the company.
Q: Where does this dog food concept come from?
A: That really goes back to the desire that we know how our products are going to work before we ship them and really test them in a way that can't be done in a lab.
Microsoft certainly has a lot of software testing right now.
This is a pretty interesting time. We just finished rolling out Windows Server 2003, which for us as an IT organisation is the accumulation of about two years of work from the first bit of code we played with. And we're rolling out Titanium -- the next version of Exchange -- and the next version of Office. Today, all but one of our Exchange servers is running Titanium, and we have about 40,000 clients running the next version of Office.
OK, so what would be the cost savings from moving to these newer products?
We haven't finished the costing, but let me give you a scenario. We have Exchange servers worldwide... The cost-savings will be hundreds of thousands of dollars around reducing servers that would have been upgraded, reducing bandwidth, and we're going to be able to reduce the maintenance and backup of those servers. Once you get Exchange Server out, you can look at all the other servers at those remote sites, which opens the door for further consolidation down the road.
Certainly there are advantages to running programs like Office 2003 ahead of their release. But what about the disadvantages?
I think it's a core competency of my group to understand when to roll (the product) out and where to roll it out. We didn't embark on this charter without lots of discussions at the executive level, about why it's the right thing to do. Essentially, should we give up trying to get the next line of availability by bringing beta software into the day-to-day work environment? We have great support from the executive staff, but I wouldn't say that support goes all the way down to every individual in the company when they're trying to get their job done and things don't work. We still have a $30bn company to run.
I assume you don't distribute beta software companywide all at once. What's your strategy?
We roll out (beta software) in a pretty disciplined way. We have a small dog food environment of about 400 users where we roll out code on a very regular basis. It's sort of undisciplined, rolling out new code as soon as it's ready to see what happens. The only clients on there are the product groups that write that (code). So there's self-inflicted pain, if you will.
Once we get to a (testing) build that meets a certain quality, we move it into an environment we call WinDeploy. WinDeploy has about 3,000 users in it. We test it before we put it in, and then we run it against that user base... Once we get through WinDeploy with adequate stability, we'll roll it into the (work) environment. Where we roll it in depends on the product. Taking Office as an example, we have to understand how that's going to interact with all line of business apps before it goes out... It wasn't until beta 2 of Office (2003) that we went very broad and moved the population up from about 10,000 to 40,000.
Previous
Did you find this article useful?
36 out of 78 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
