After the holiday break things got really busy around here, and again I feel like a human interrupt service routine. I don’t have time to read everything I need to, let alone write. I apologize for dropping off, and thanks for the feedback on my previous blog entries.
Here at Microsoft we have a sophisticated process for conducting market research. The output of that process is a carefully crafted set of requirements for each release, with an accurate prioritization, cost and risk mitigation model for every feature. This is then turned into a detailed milestone schedule with clear exit criteria for each milestone. With near perfect planning, projects then proceed like clockwork.
This is as believable as some of the conspiracy theories about us, that, while entertaining to read, would require a degree of organization and coordination that we only dream about. Software is complex. We do our best.
One of the unfortunate side effects of very large software projects that ship on a global scale is that we think “we’re done” a rather long time before we can release the product. We’re not really done, we just stop adding new features and changing things and enter a cycle of testing and fixing, and testing, fixing, more testing and fixing.
The .NET Compact Framework Version 2 is entering the final testing cycle now. We are starting to plan for the next release. I would like to ask for your input into the evolution of the product, and I would I encourage you give the Beta 2 release a good shakeout as soon as it is available. It is a goal of ours to allow apps written against Version 1 to run unchanged against Version 2. With over 5000 public APIs, this is a tough problem but I feel good about our progress. I encourage you to report app compatibility bugs (and all other bugs) to us and we will try hard to fix them for the final release.
Let me share some history on how we “planned” the .NET Compact Framework product evolution, starting 5 years ago. We really were only certain of a few things:
There was a hole in our product line in the “sweet spot” between C++ and Visual Basic. Visual Basic offered the productivity of modern typesafe, garbage collected languages, but was tuned for business applications. C++ offered flexibility and power but not productivity.
COM and OLE , while enabling rich, graphical multi-vendor in process extensibility, were relatively complex technologies to master.
Each of our language offerings had a different “standard library”.
The diversity of products and requirements built on top of Windows CE, and the rapid pace of embedded and mobile hardware evolution had created a situation where Windows CE Win32 API compatibility across operating systems versions and across products was a source of developer frustration.
A healthy developer community is very important to the success of any platform technology.
The world didn’t end in 2000 and gasoline generators were going on sale.
The list of things we didn’t know was much larger, including:
What should the target size of the .NET Compact be? J2ME was tiny, but was it useful? Should we aim to enable simple games on 20MHz processors with 32K of RAM, or business applications on 200Mhz processors and large amounts of storage?
How big would the apps be? Where is the sweet spot for performance optimization? Should we shrink the footprint, or work on scalability?
How much should we worry about API consistency across platforms?
Would people want a rich visual design experience, or would command line development be OK?
How important was Win32 interop? Would applications be mixed C++ and C#/Visual Basic?
Would everything be running in a browser frame by 2005? Did that make sense on devices?
How big would screens be? Would the phone kill the PDA? Would the portable game kill the PDA?
How fast would wireless networks evolve? What standards would win?
How much higher could pets.com go? Had the entire world gone crazy?
These are the decisions we made that I feel have served us well:
Compatibility was key. We would not have a different executable file format. We would enable rich protocol level interop whenever possible and we would set a very high bar for API level compatibility with the larger .NET and across product and device versions. This decision had an unseen cost in terms of product footprint that we really didn’t understand until later in the cycle, but I still think the net value to customers was very strong.
Great visual design tools were important.
Rich, accurate emulators were important.
Remote source level debugging is important.
Databases were important.
Quality was important. We were asking people to make a bold step and bet on something new; it had better be great.
We learned a few lessons:
Our hardware targets we’re too low, which led to low estimates about how large and complex applications would be. The first applications we saw really pushed the CLR to the limits, and we had not sufficiently optimized for “upward” scalability.
We cut a few things, which, in retrospect, seem downright silly: DateTimePicker, MonthCalendar. Actually, I’ve now use the term DateTimePicker in the team to mean “any silly feature we cut”, usually in the phase “are we sure that’s not a DateTimePicker?”
More people relied on serial ports than we thought. Also, MSMQ.
Interop was super important. Our P/Invoke support was not rich enough.
Windows Forms abstractions would not completely replace and hide the underlying Windows implementations, and many customers wanted to live in hybrid world. Our Windows Forms extensibility was not rich or formal enough.
Embedded developers are very smart, and like to write very complex applications.
ActiveSync as a debugging and deployment transport needed some attention.
Logging, diagnostics and performance instrumentation are very important.
Games are important. And fun too.
After Version 1, we released SP1 which added support for Smartphone. SP2 included significant performance gains around XML, ADO.NET and resource management, in addition to support for landscape/portrait switching. SP3, just released, is a fairly minor bug fix release.
In Version 2, we have added the ability to call COM components, enhanced P/Invoke, added to the built-in Windows Forms feature set and enhanced extensibility, added support for DirectX, MSMQ/System.Messaging, ResultSets, generics, and did lots of performance work (and fixed more than a few bug along the way).
Looking forward at the areas where I think we can still do better, the big one that see is around making it easier to deal with transiently connected networks. It’s still way too hard to write robust networked apps on devices. To start with, it’s hard to know what network you are on and what the performance and cost of that network are. It’s hard to “switch” networks. Oddball networks like IrDA, Bluetooth and SMS/MMS are poorly integrated at just about every turn in the road. Even 802.11 and GPRS don’t work as seamlessly as they should.
The only really common quality that the networks we use on devices have is that they are often crummy. Networks can “disconnect” and tear down TCP connections, they can “disconnect” and allow TCP connections to stall for very long time and they can just “go away” for while.
This is one area that we intend to work on for V3, by leveraging the work that has been done on the WS-* protocol suite, and adapting it to a device environment.
Of course, performance is always important, and we will continue to make improvements.
I welcome feedback on these priorities.
Finally, no blog entry from Mike would be complete without a shameless plug for www.zintel.net. I’ve posted one new photo that I’d like to share:
This posting is provided “AS IS” with no warranties, and confers no rights.