Building A Services Platform – An Ode To Redundancy

Microsoft is a platform company which means that we like to take re-usable bits of functionality, wrap them up and make them widely available. The problem is that when a bit of functionality is not well understood trying to create a platform feature to address it will almost certainly result in something that either functions badly or not at all. The trick to good platform design is to know what to leave out and anything that deserves the title "Research" must be in the 'leave out' category.

In the services world there are numerous problems that richly deserve the title "Research". Almost anything having to do with latency optimization for read/write or real time data, most interesting security problems, almost all interesting privacy problems, just about all worthy service development language/IDE problems, etc. These are all areas that everyone is grappling with but which aren't well understood and where the industry needs to experiment.

But as this experimentation goes on the end result is what looks like a lot of redundancy. As each service deals with its own variant of the previously listed issues they tend to re-invent what looks like the same functionality. This sort of thing drives management batty because redundancy == waste in their minds. But it a'int necessarily so. Redundancy can be incredibly useful when it is stimulating learning. It is exactly this sort of redundancy, both within Microsoft and across the industry, that gives us the experience we need to move a problem from 'Research' to 'Development' and then into the platform.

Nevertheless I get more than a few odd looks from my fellow Microsofties when I explicitly say "Yes, I know your feature Y looks like something Group X is doing but Group X hasn't shipped their feature and anyway feature Y isn't well understood. So please, ship! Ship! SHIP!"

But really, my fellow Microsofties shouldn't be at all confused. A true platform maven doesn't believe in 'do it once', a true platform maven believes in 'do it right'. Until we know what 'right' is we need to experiment.