Microsoft, eat your own dog food

"Eating your own dog food" is a concept that may not be so familiar outside the development community, and is not intended as a reflection of the quality (or lack thereof) of a particular software product. In essence, it means that if you create an API or product within a company, it behooves you to ensure that your own developers also use that product, turning them into in-house field testing personnel with the added advantage that they have access to the code and can find, if not fix themselves, truly annoying deficiencies.

I think it's pretty clear that where Microsoft has truly eaten its own dog food, it has made products that manage to control a large percentage of the market. Consider something simple and fundamental which historically has been as closely associated with the Microsoft platform as WIN32: COM. COM was Microsoft's standard technology for binary interoperability. Built around a simple C-style binary layout that maps directly to the way C++ implements virtual methods (the VTABLE, which is basically a stack of function pointers), it became the de facto interoperability standard atop the Windows platform. A heavy percentage of my C++ development work in the past was devoted to the creation of reusable COM components. COM was an extremely important technology pre-.NET, and for that reason, Microsoft made sure that COM interoperabilty was incredibly simple to achieve from .NET environments. You can generate .NET wrappers around COM objects very easily, allowing you to manage legacy COM objects in your .NET applications as easily as you do local .NET objects.

COM, however, conquered the Windows world because Microsoft was so aggressive about using the technology in its own products. A true competitive differentiator, at least from a "browser as reusable toolkit" standpoint, was the fact that Microsoft built Internet Explorer as a set of reusable COM components. All functionality in Microsoft's Office product suite were exposed via COM Automation, making the functionality accessible to both developers using traditional programming languages and scripting languages alike. Microsoft made Visual Basic an important development technology based in no small part on how the tool made it easy to create and consume COM objects.

Microsoft, in other words, ate its own dog food when it came to COM. This incentivized third parties to use the COM infrastructure in their own products, making COM the standard technology for binary reusability in Windows.

Low-level technologies, however, aren't the only beneficiaries of the "dog food" concept. Higher level products also frequently benefit from extensive internal usage by Microsoft.

I don't find many opponents of Microsoft technology who have bad things to say about Visual Studio. It is generally considered a great product, and the fact that many of its concepts are copied in competing development tools is a testament to its status as a setter of trends in development technology. People may complain about its price, but they don't often claim that it is a bad product.

Visual Studio is also the tool that Microsoft uses to build all of its own products. That's a huge competitive advantage for a company like Microsoft, which is chock full of highly skilled developers and creates software used by billions. Those experiences inform directions in a product they use to build their own software, and since software developers who write to Windows are likely to have many of the same requirements as Microsoft's developers, that improves Visual Studio's suitability to the needs of Windows developers.

Few companies are as driven by email as Microsoft. I received stacks of the stuff while a Microsoft employee, and combined with the integrated calendar in Outlook, it served as the primary means by which Microsoft coordinated things across a large and diverse company. That internal experience has helped to inform the design of both Exchange and Outlook. Microsoft is in a unique position to know what kinds of issues large distributed organizations face from a communications standpoint because it is such an organization itself, and that knowledge has been poured into the design of Exchange and Outlook. That, I think, has played an important role in making the pairing dominant in the enterprise.

The "eat your own dog food" model has its limitations. Everyone at Microsoft uses Microsoft operating systems, too. That has worked well in the server space, where the server operating system division has moved from strength to strength, and has a growing market share to show for it. Having the geeks at Microsoft using a consumer-oriented operating system, however, is less effective at working out issues that affect non-technical users, as geeks are a more knowledgeable user group than the non-geeks that constitute the majority of users of desktop Windows. This has created an opening for consumer-centric Apple, who has created a team of people plugged into the needs of non-technical users. That's an important issue that Microsoft needs to resolve, and a lesson to be drawn from their experience of Vista, as well as their competition with a newly-resurgent Cupertino-based competitor.

Limitations aside, the "dog food" approach to software development is still highly effective for Microsoft, particularly as they are a company who tends to make the tools that others use to build higher-level solutions. More rigorous enforcement of that principle, I think, would help Microsoft considerably, which is the nice way to say that I think Microsoft has failed to "dog food" some critical technologies, which is weakening their attempts to popularize them in the marketplace.

I can think of certain products that aren't used extensively within the company, and should be. But more important to me as a developer who prefers the .NET approach to software development, however, are the technologies released as part of the .NET 3.0 package, and in particular, Windows Presentation Framework (WPF).

WPF was designed as a modern replacement to the legacy WIN32 user interface technologies. Unfortunately, as Peter Bright in a long response to a previous article noted, there is a dearth of WPF-oriented applications made by Microsoft. This leads to justifiable questions as to whether Microsoft truly considers WPF the future of user interface development atop the Windows platform.

Microsoft would go a long way towareds making WPF the de facto standard development technology for Windows if they started churning out large numbers of applications that use the technology. If they aren't willing to do that themselves, why should Microsoft expect the wider world to embrace WPF with any more enthusiasm?

Pushing WPF more strongly among their own products would certainly help to popularize Silverlight, built as it is on a subset of WPF and thus serving as a point of consistency between desktop development and Rich Internet Application (RIA) development. On that note, If Microsoft doesn't aim to make Silverlight spread from desktops to TV Set-Top Boxes and portable devices - all properties in which Microsoft has a strong showing - then Microsoft is fighting RIA-dominant Adobe (with its Flash product) with both hands tied behind its back. "Dogfooding," in other words, should apply to more than just desktop-oriented products.

Microsoft needs to be the canary in the mine for its own technologies, which sounds less dramatic when you consider that that canary owns the mine, is super-smart and has the ability to rapidly put together air filtration systems to clean up any dodgy air it might find. Pressure to achieve this goal can only come down from the center, I believe, which is why I think there needs to be a strong voice at Microsoft that creates a coherent story for the platform as a whole, and guides the technology directions taken by individual divisions.  If there is no strong centrally-managed technology vision, then you can't complain when people fail to adhere to it.

I remember broaching this concept to friends and colleagues at Microsoft before I left, and though the response from most was positive, some stated that they liked the Microsoft hands-off approach to development. I am not, however, so sure that the current hands-off approach is the way Microsoft has always operated. In a response from Bill Gates to a Thinkweek piece I wrote (the nature of which I am not at liberty to share), I came away with the strong impression that there was once a time that there was strong pressure on new divisions to leverage and promote technology created by other divisions, and that this had become a problem over time. This was why XBOX had been freed to chart its own path, in hopes that the demands from other divisions wouldn't strangle Microsoft's attempts to pose a credible competitor in the console gaming space.

It's one thing to prevent MSN content properties from trying to get space on the XBOX blades for their own products. Its another thing, however, for XBOX to be allowed to disconnect in any appreciable way from the wider Microsoft product ecosystem.

Microsoft, again, is a platform company. It works best when everything they build is an extension of that platform, not just because that makes the platform as a whole valuable, but because it leverages the unique investment in software platform expertise that the company has built over the years.