The most successful shared components used internally at Microsoft.

  • Article

Recently, I reflected on all the cross team components we depend on for Windows Live Writer.  Then I thought about the ones that have worked out well for us.  I didn't think about platforms Microsoft makes like .NET, GDI, DirectX, etc… Instead I thought strictly about things that our ISVs never(or rarely) see, but one team at Microsoft delivers it to another team(s). 

1) SQM - Software Quality Management

SQM is what almost all programs at Microsoft use to gather information about the way customers use applications when they have opt-ed into the CEIP.  It is never used to monitor individuals or to help Microsoft identify individuals.  It gives us a broad sense of how an application is being used by the masses.  For example mspaint might track what the most popular colors are.  If they find out the one of the most popular colors is a custom color not in the normal palette, the team might decide they want to add this color as one of the defaults. 

2) Glinks

Glinks is a system run by one of the web platform teams.  Teams simply provide a mapping file that map one URL(Microsoft controlled) to another URL.  You can think of this of a url shorten that is used client applications to prevent hard coded links in application from going bad.  For example, in Windows Live Writer we use a glink for the YouTube privacy policy link.  That way, a few months down the road, if YouTube changes the URL for privacy we can update the mapping file on the server and the problem is solved without updating the actual client.

3) Watson

Watson is an error logging component that will track when an application crashes and send back data to Microsoft if the user chooses to do so.  You know those “Would you like to send the report to Microsoft?” dialogs that come up and most users think go to a black hole in Bill Gate’s basement… that is exactly what I am talking about!  Those actually get picked up by product teams at some point so they can fix bugs.  Since the time I have been on the Windows Live Writer team, we have fixed a some serious bugs we wouldn't have found otherwise (so keep those reports coming!).

What do they hay all have in common?

These 3 components all have a few common traits.  First, they all just work, they rarely have problems and when they do they have very limited impact and are fixed quickly.  Second, while they might have originally been created for a specific team with specific requirements; this is no longer the case. These are one way relationships where one team makes something and another teams consume them.  This leaves no room for consumers to impose changes on the component that increase the chances other teams have problems using the component. Third, they have a low barrier of entry because the system is so easy for teams to setup.  If all internal projects were like this it would be great, but it turns out that over time systems grow and become harder and harder for other teams to use.

Comments

  • Anonymous
    April 22, 2009
    The comment has been removed