In the late 90s, I worked on the IrDA infrared connectivity technology. My team built the protocol stacks that shipped with Windows CE and Windows 2000 and descendents, and I was an advocate of the technology within Microsoft.

IrDA is a success. It continues to be useful as simple way to transfer files and contacts between devices and PCs, and to use phones as modems.

That said, the thing I was most passionate about failed. I wanted to create the most seamless experience for moving photos between digital cameras and PCs. Keep in mind that 8 years ago, it was trivial to draw a crowd by taking a digital camera to the zoo. And my internal demo of a pre-production digital camera beaming images to Windows NT5 was very cool indeed.

There was a “competing” internal technology called Windows Image Acquisition (WIA) architecture. WIA abstracted various lower level buses, normalized the command and data transfer, and exposed the camera photos through a standard API that can be used by many different programs. In theory, WIA and IrDA would coexist, but I disliked it. A WIA camera was installed via the PnP system as a new device, and controlled via APIs and control panel.

I argued that we had created an essentially new model of connectivity, completely free of state and configuration and completely ad-hoc. No drivers to install, no settings to get wrong, and wrapping this in PnP was ugly from an engineering perspective and bad for ease of use.

I was quite passionate about this, and the company empowered me to ship it in Windows 2000. I even lined up some camera vendors to support it. And I was sure I would win in the marketplace because of the fundamental beauty of what we had built.

It was beautiful.

I don’t know for sure, but I suspect that, today, if my one unit of the one camera model that I know actually shipped with this feature wasn’t broken, I could point it at my XP laptop, hit send, and all of my photos would be transferred to a folder. The folder would then automatically open to an Explorer photo preview model. This might even still work in Vista.

Slick as can be.

But it failed. Worse, partners who bet on me failed. I didn’t make life easier for consumers. I left Windows with legacy (but good quality) code to support. And I now am a regular and happy user of WIA to import images from one of my two scanners into any number of image editing tools that I use on a regular basis

Why am I telling you this story?

The software platform business is fundamentally different from an innovation and marketplace perspective than, say, the 3M model of product incubation, entrance, success or failure and withdrawal (at least as it’s taught to me by B-School types; I’ve never worked at 3M and one thing I’ve learned is that you never quite get it from looking outside in).

First, you can’t really withdraw things. At the scale of Windows, even if a small percentage of folks take a dependency on a technology, then you want to continue to support them.

For a long time.

DOS apps I wrote in 1980 continue to run on XP today. I’m sure if the folks writing DOS knew this at the time, they would have made this task a bit easier.

.MODEL LARGE ; large model

.CODE

PUBLIC _TestForKey ; BOOLEAN TestForKey(void)

_TestForKey PROC

mov ah, 1 ; Key waiting check

int 16h ; Keyboard BIOS service

mov ax, 0 ; Assume no key waiting

jz Return ; correct, return(FALSE)

mov ax, 1 ; Key waiting, return(TRUE)

Return:

ret

_TestForKey ENDP

It's important to get things right for the long term.

Second, the net value to people of a feature is not measured in isolation. Frankly I don’t want to choose between 10 different ways to do the same task and decide which one I like best. I want one way to discover and start programs, one way to cut and paste, one way to organize things, one way to add and manage devices and administrate my machine, etc. Once I’ve learned how to do things, I want to do them the same way in as many places as possible. Perhaps most importantly, I want programs and hardware I buy anywhere to work anywhere.

You might think we could have done a better job on some of these things, and I’d agree, but it’s not for lack of trying. Our software is used, literally, by hundreds of millions of people, in every country in the world, to do an incomprehensibly large number of different things. An interesting consequence of listening and acting on a huge number of feature requests, each that make sense in a scenario, is that you can accidentally end up doing a bunch of overlapping things. Frankly the search for the fully normalized horizontal, discoverable and easy to learn and live with solution to problems is not an easy task.

Some of use who have been around for a while remember a simple happy time when you wrote some code, put in on floppy, took out an ad in Byte, and made a fortune. Personally, I’m going to ignore the fact that this wasn’t at all my experience trying to bootstrap a software company, and remember it this way.

Why am I telling you this story?

I’ve been spending the last few months doing “cross group” work, to get something new lined up and right for the long term.

We spend a lot of energy and time at Microsoft these days doing cross group work. On a great day, this can be an enlightening and enjoyable process, as we have an amazingly diverse, talented, curious and interesting group of folks here. I can’t imagine a faster way to gain rich insights into technology, customers and the marketplace. On a grumpy day, cross group work feels like a game of whack-a-mole that has gone on too long, as the shear number of opinions and innate complexity can be overwhelming.

And this work has been “secret”. Not so much because we want to save the surprise, but because we want to make sure that we don’t announce things until we have very high confidence that we will be able to build, ship and support them, that they are the right solutions and that we understand how they sit relative to other potentially overlapping efforts.

I once wrote about what we knew Vs what we didn’t know when we designed the .NET Compact Framework.

I’d like to tell you now what I know about the game space. I know that very high end games are written in C++ , with a significant art component, and are getting more expensive to build. I know that C# improves programmer productivity substantially and has very solid adoption and customer loyalty. I know that at the low end, various technologies are making “casual” game authoring much easier, and that devices are a high volume target for these games. I know that the set of technologies used to write games varies significantly across platforms, and that it’s hard to migrate code and skills between consoles, PC and devices.

I also know that working with the Xbox team has been among the most enjoyable and productive cross group work that I’ve done. I know that my team and the XNA team within Xbox, have been burning the midnight oil to allow us to demonstrate the feasibility of games written in managed code running on a .NET CLR on a final 360 dev kit. And I know that we’ve demonstrated the same game binary (almost the same; oh so close) running on the 360 kit, Windows and on Windows Mobile.

 

In HD.

Fast.

Stay tuned.

 

For the record, the right solution to the photo exchange problem proved to be tiny solid state drives that are PnP’d as a local filesystem.

 

Mike.

 

This posting is provided "AS IS" with no warranties, and confers no rights.