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.
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.