VC++ product strategy: the next level of detail

Thanks to everyone who provided feedback on my last post on VC++ product strategy.  While I totally appreciate and value the feedback, I have to admit that a few responses did leave me with more questions than answers.  I'd like to therefore first call some of these things out and then I'll share some of my other thoughts on your comments in the hope of getting your input on this next level of detail.

It's about strategy, not features
While the feedback I am seeking is about VC++ long term strategy,  many of you provided feedback about your preferences for devoting resources to this feature or that feature.  While throwing a big feature or two into your list is okay, I'm really more interested in your thinking on where Visual C++ should go as a product.  When done right, features should be a manifestation of the overall product's strategy -- features are implemented in order to accomplish some larger goal or enable some specific scenario.

While I would be inclined to try to reserve maybe 15% of the product unit's resources for "random" features and customer requests, 85% of the PU's effort should go into that feature work intended to fulfill a larger end goal.  It's that 85% I really want your feedback on.

The standards dilemma
Several of you called out improved standards compliance as an area of key strategic investment.  I'm all for this, as standards compliance is the enabler of multiplatform C/C++, and many VC++ customer use C++ in order to write platform or vendor agnostic code.  However, since blogs are about being frank and honest, I'll just come right out and say that I don't agree with the level of investment in standards that several of you recommended.  For example, one reader thought we should be investing 90% of our resources in improving standards compliance, and other recommendations on the higher side included 75%, 40%, and 30%.

Again, here the focus is on standards conformance as a feature, which I don't think is the most profitable way to view conformance.  Conformance should be a means to accomplish some end.  What is it that you're trying to accomplish that our currently level of conformance will not enable you to accomplish?

Given that Visual C++ 2005's level of standards conformance is among the best -- in the upper 90's percentage-wise -- it's difficult for me to see how a continuous and massive investment in this area could be justified.  This is particularly true when I look at some of the many potential investment areas where we can make a real and dramatic impact on the day-to-day productivity and happiness of VC++ developers.  I'm speaking about areas like build throughput, IDE code intelligence (e.g., Intellisense, refactoring, etc.), integration with MS online services (Connect, Windows Error Reporting, etc.), concurrency, native/managed interop, and the like.

C++/CLI designers
At least one of you asked for XAML support in C++/CLI.  This one is interesting to me, and I'd like to hear your feedback on it.  One school of thought is "language parity," that we must try to support everything in C++ that we support in the managed-specific languages.  Another school of thought is that we should let each language evolve in potentially separate directions if that enables developers to fully exploit the capabilities of each language.  Honestly, I'm finding myself increasingly in the latter camp.  For example (and this is totally off the top of my head), what if we made the interoperability between C++ and C# really, really great and you could easily use the C# XAML designer in your otherwise C++ project? Is this a bad thing or a good thing? I can see arguments both ways, but I like the idea of not expending my team's effort on "keeping up" with C# in areas where interop should suffice and instead using my resources to innovate in other areas where C++ adds more unique value.  What do you think?

Surprise: Mobile
There were a couple of things in your comments that were surprising to me, such as the desire for better mobile devices support, particularly for C++/CLI.  Slight organizational digression: the VC++ team doesn't own the mobile agenda -- that's owned by the Visual Studio for Devices team.  However, we work closely with that team, as we provide a number of core technology pieces upon which they build devices support into VS.  Serious question: why is it important to many of you to support C++/CLI for .NET Compact Framework? It is because you prefer the C++ language to C# or are there more specific technical reasons why you seek C++ /CLI support for .NET CF?

No surprise: better optimizations
Many of you called out speed and efficiency as important areas of investment.  We agree.  In fact, we agree to such a degree that we have spun our code generation team off into a completely separate product unit.  This product unit is building a new, optimization and transformation-friendly, compiler back-end based on MSR's Phoenix framework.  While you won't see the fruits of this investment in Orcas, it is definitely an area of substantial investment that will begin bearing fruit for VC++ developers in the post-Orcas timeframe.

Also no surprise: improve the native experience
Both the native and managed platforms are important to Microsoft.  We continue to innovate in both areas, with Windows Vista providing both a host of new native APIs as well as the impressive managed code innovations in .Net 3.0.  Visual C++, being the one Microsoft programming language that enables developers to target the native platform, is obviously a key piece of the overall native code strategy for the company.  So, it's not surprising that many of you would ask for improvements to the native code developer experience.  This message has been heard, loud and clear.  We do intend to invest heavily in the native code experience going forward.  I'll discuss this topic in greater detail as the specifics of our strategy solidify in the coming weeks and months.

Your questions
Finally, I'd like to answer some of the specific questions some of you asked of me in the comments...

Would Connect not be a better forum to generate feedback?

I'll answer that one with a polite-but-firm, "no." :) Connect is about providing a platform for Microsoft and customers exchange information about specific bug reports and feature requests.  Connect is not the best place to have a conversation about the various elements of product strategy.  Remember, I'd like to raise the level of this conversation above the specifics of this bug or that feature, and Blogs are better venues for conversations in general.

Is the VC++ team in charge of the MFC or is it the Platform SDK team?

Yep, we do.  The VC++ team owns the native C/C++ libraries, including MFC, ATL, SCL, and CRT.  The SDK team owns the headers and libraries for the Windows platform.

Will Vista still be the target OS for the post-Orcas release, or will it be Vienna?

It's still too early to say.  Right now we know that Orcas will target Vista, but it's too early in both the Vienna and Orcas+1 cycles to know whether Orcas+1 should sync up to Vista or Vienna.

Is Win32/Win64 here to stay?

Indeed they are.  And VC++ will be the tool used to target the native platform.

Will native and managed development co-exist or is native evil and responsible for all security problems of Windows?

Well, two things *can* be equally true.  :)  Yes, I believe that native and managed development will co-exist for the foreseeable future.  And, yes, it is easier to shoot yourself in the foot from a security standpoint with native code.

Look, native doesn't have to be evil for managed to be valuable.  And, likewise, managed doesn't have to be evil for native to be valuable.  They're both important and strategic platforms for Microsoft.  There are great APIs and libraries in both the native and managed world.  I believe an ongoing challenge for the VC++ team is to make managed/native interoperability so efficient and seamless that developers feel free to choose a library or API based on its suitability for their needs, not based on whether it's a native or managed library or API.

We've also done a lot of work in both the libraries and the compiler space in making the native world more secure, with the understanding that developers focused on native code also need better security technology.

Thanks again for all of your comments and a look forward to a productive round 2.  :)