Microsoft Responds to Development Tools Discussion

[Andy Sjostrom]

We have discussed the ongoing changes on the mobile application development tools arena during the past few weeks. I first posted on the subject in the <a href="http://www.pocketpcthoughts.com/forums/viewtopic.php?t=9915">"Is Free a Make or Break Issue?"</a> (Mar 11) and continued and tried to conclude the discussion in the article <a href="http://www.pocketpcthoughts.com/forums/viewtopic.php?t=11092">"Be Free Or Not Be Free"</a> (Apr 10).<br /><br />Yesterday, I got an e-mail from David Rasmussen, Lead Product Manager for the .NET Compact Framework, with a response to the open questions. David Rasmussen does a good job in explaining the strategies and thinking, and I am sure many will like what he says about a standalone .NET Compact Framework SDK. Click "more" to read the entire response.<br /><br />"Hi,<br />I'm the Lead Product Manager for the .NET Compact Framework at Microsoft. I'm sorry it has taken a while for us to chime in on this, but we've been digesting a number of things and we've been kept fairly busy recently with our launch.<br /><br />It's good to see so much debate and interest in this topic, and it is certainly helpful for us in thinking about our plans. We are listening.<br /><br />Much of Andy's assessment is on the mark. There are several reasons behind including device development capability in Visual Studio .NET. First, it enables a mass of Visual Studio desktop developers to very easily build apps for devices right out of the box (click a different project type, same IDE, forms designer support, same coding model, consistent classes etc.), we think that's a good thing for the Pocket PC market that will drive a lot more apps from developers who aren't targeting them today. Second, it brings the device coding experience up to par with the desktop experience, anyone who coded with eVB and Visual Studio knows the difference in capability of these two environments. We wanted to eliminate that disparity and give device developers the best possible IDE and development environment we could. Third, it allowed us to do more with the resources we had. Taking this approach of integrating with Visual Studio we can take advantage of all the investments in Visual Studio (IDE, designers, compilers, testing teams etc.). If we had a completely separate set of tools, those same resources would have to invest more time in redoing all this work and less time in adding great new features. <!><br /><br />There are several reasons we charge for our tools, revenue is obviously one of them, but most importantly, that money is what enables us to continually reinvest in those tools. Free tools tend to get stale and get less attention and investment in innovation (that's part of the reason eVT was lagging desktop tools in terms of features). Also, it imposes a certain amount of discipline on us to force us to continue to innovate, improve and demonstrate value to our developer customers to justify the price. We think that this approach has proven its value over the years, there are free tools out there, but millions of people continue to buy Visual Studio for good reason. We hope that all of you who've tried Visual Studio .NET and .NET Compact Framework will agree that we've made some pretty dramatic improvements in the device development experience and set the base for a lot more innovation to come, and many developers seem pleased to be able to get the value of that even if for a certain price (rather than it never making it to the market at all...).<br /><br />I'd also like to address the specific point of the SDK. The fact that we don't have a stand alone SDK for the first release of .NET Compact Framework is regrettable. It's not an explicit part of our strategy. It fundamentally came down to a resource constraint. We really wanted to ship the .NET Compact Framework as soon as we could and we wanted to keep the feature set high. Several things ended up getting cut to meet this goal. A standalone SDK was one of them (there's more work involved than one might expect). We knew this would be a painful cut, in hindsight it's probably even more painful than we anticipated. It is our intent to offer an SDK for the next release of the .NET Compact Framework, so hopefully that clarifies our intent for the future.<br /><br />And on one final point regarding the different audiences Andy describes, it was definitely not an explicit part of our strategy to trade off making things easier for existing Visual Studio developers at the expense of hobbyists. We love hobbyist developers, most of us here in the developer division at Microsoft (including the marketers :-) are hobbyist developers in our spare time. Hobbyists always add a richness to any platform. But as you can see above, we had multiple input factors leading us to include the device development features in Visual Studio .NET and overall we thought it was a significant advantage for the majority of our customers including hobbyists. We do try to address this community in several ways with special pricing programs like Academic pricing and cheap upgrade pricing, also we license Visual Studio to enterprises on terms (per developer) that allow developers who use Visual Studio at work to also install it on their home machines for use at home for their own projects. Many device hobbyist developers are professionals by day. We know that these programs unfortunately don't cover everyone, but we do try.<br /><br />Thanks for all the discussion and input, and for those of you using the Visual Studio .NET and the .NET Compact Framework, I hope you've been pleased with the value of it."

[Kevin Daly]

That's a pretty good response, although I still don't understand why the device development tools can't be provided with all versions of VS.NET 2003 (unless there's been a change to that policy while I wasn't looking, which is always possible. But probably just wishful thinking).
It is good news about the future SDK, that will certainly help. With a naked SDK, development ain't pretty but at least it's possible - plus there's an opportunity for third party developers to produce an IDE.

[Peter Foot]

That's a pretty good response, although I still don't understand why the device development tools can't be provided with all versions of VS.NET 2003.

I fully understand the reasoning behind pushing the rich power of VS and the complications in supporting SDK compilation. However sadly there was no discussion about the single language products. You've got the full power of the Visual Studio environment, I can see that Microsoft could generate some useful revenue and better support the smaller developers by shipping the functionality with C# and VB.NET single language products. And I don't believe this would dent the revenue generated from the enterprise community who would still use the full visual studio enterprise package for the additional functionality. This would be an excellent opportunity for hobbyists etc to move up from eVB.

[Tim Allen]

I don't think this reponse from MS is satisfactory at all. It seems to boil down to 'we do like hobbyists, but we'd rather make as much money as possible out of them'. Well they aren't going to get many hobbyists forking out $1000, it's just too much of a jump from the current $0 they're used to.

Message to Microsoft - forget the SDK, just sell me a version of Visual C# that I can use to write Pocket PC apps. This doesn't seem to me to be a technical limitation or require a lot of development effort, it's just a marketing decision. I have $100 sitting here waiting for just such a product...

[Peter Foot]

I don't think this reponse from MS is satisfactory at all. It seems to boil down to 'we do like hobbyists, but we'd rather make as much money as possible out of them'. Well they aren't going to get many hobbyists forking out $1000, it's just too much of a jump from the current $0 they're used to.

Message to Microsoft - forget the SDK, just sell me a version of Visual C# that I can use to write Pocket PC apps. This doesn't seem to me to be a technical limitation or require a lot of development effort, it's just a marketing decision. I have $100 sitting here waiting for just such a product...

Exactly, there was no mention of the single language products, and they have been a key part of the whole argument here. I don't think its simply a case of expensive or free - its a case of what is affordable for each type of developer - VS 2003 is fine for the enterprise, hobbyists etc are best suited by a single language product and there is no reason why the functionality can't be sold with these products because the IDE is the same.

While its nice to know that more choices will be available in the future that doesn't really excuse the current situation. It is a shame that the platform is being held back here not by technical limitations but blinkered marketing decisions.

[gorkon280]

There are other free compilers that are not stagnating. The only reason the Microsoft eVB and eVC stuff stagnated was that they let it stagnate. This as well as other reasons are what make me believe that Linux will one day rule everything. I can by ONE disc and install it on many computers and it cost me only for the cost of the one disc and in some cases, all you have to buy is the 1 dollar blank CD and not only do you get a full OS but you get the development tools as well. Personally, I can buy the new VS.NET cheaper where I work (educational discount). Anything I would produce would be free anyway (GPL'd if possible).

[Kevin Daly]

I don't think this reponse from MS is satisfactory at all. It seems to boil down to 'we do like hobbyists, but we'd rather make as much money as possible out of them'. Well they aren't going to get many hobbyists forking out $1000, it's just too much of a jump from the current $0 they're used to.

Message to Microsoft - forget the SDK, just sell me a version of Visual C# that I can use to write Pocket PC apps. This doesn't seem to me to be a technical limitation or require a lot of development effort, it's just a marketing decision. I have $100 sitting here waiting for just such a product...

Exactly, there was no mention of the single language products, and they have been a key part of the whole argument here. I don't think its simply a case of expensive or free - its a case of what is affordable for each type of developer - VS 2003 is fine for the enterprise, hobbyists etc are best suited by a single language product and there is no reason why the functionality can't be sold with these products because the IDE is the same.

While its nice to know that more choices will be available in the future that doesn't really excuse the current situation. It is a shame that the platform is being held back here not by technical limitations but blinkered marketing decisions.
(Sorry for the large quote)
I think that sums up the situation pretty well. If there is any technical obstacle to including the device extensions in single language versions of Visual Studio.NET I have not heard it, nor for that matter have I heard a business reason for doing so
AsI have said in some of my previous, less restrained rants, the likelihood of someone who would not otherwise be buying the Professional or Enterprise Architect versions forking out the extra for the purpose of doing device development seems remote. So holding out for the upgrade margins seems an unproductive motive. While it's true that Microsoft do offer some good pricing/upgrade/licensing options, they don't cover everybody. I think we are all aware that there is no firm division between the hobbyist and A Very Small Business Indeed, If Only For Now...so why exclude any potential developers of software that might well attract more users to the platform?
In all honesty I don't see anything particularly sinister or cynical here, just an unfortunate and fairly random marketing decision. I personally think that with the device extensions included, the single language versions would sell like hotcakes to people who are never going to buy the Professional Ediiton or higher.
So unless there is a good, previously unrevealed reason for excluding the single language versions, I only hope that someone in a room somewhere in Redmond will have a "Doh! ...Gosh, next they'll be telling us they don't love Clippy!" moment, and quietly schedule a smart device extensions-ish patch for the single language products.
Soon.

[Andy Sjostrom]

If I am not mistaking, the single language product question is very much related to a standalone SDK both technically and from a life cycle perspective. Had the .NET Compact Framework been packaged into a separate SDK, then I assume that the efforts involved to open it up from a single language product would be much less. Now it is not which brings me to resource constraints...

I have been to many face-to-face meetings with .NET Compact Framework product managers to know that David's "resource constraint" argument is true. The team fought hard against deadlines, feature requests, footprint constraints, performance optimizations and so on. Add to these tasks the huge testing efforts related to VS.NET and single language products and you have a stressed out group of people. I have no intention to answer on behalf of David, but I suspect that Microsoft will come around to address the single language product request eventually.

And as we know Microsoft is listening, keep the feedback coming! 8)

[Peter Foot]

If I am not mistaking, the single language product question is very much related to a standalone SDK both technically and from a life cycle perspective. Had the .NET Compact Framework been packaged into a separate SDK, then I assume that the efforts involved to open it up from a single language product would be much less.

I disagree, I think there would be a lot more work in producing an SDK. There are already significant differences in terms of compiler functionality etc between the desktop SDK and VS .NET. Add to this the differences in the underlying workings of the Compact Framework which are a simplified version of their desktop sibling, and the major changes in the forms and control support and you have a lot of work to do.

However back to the single language products... These use the Visual Studio IDE and therefore the same compilers as the VS .NET Enterprise version. Therefore I don't think there would be significant test resources required to test either VB.NET or C# .NET because they are essentially a custom installation of Visual Studio with only a single language installed. I could do a custom installation of VS .NET 2003 choosing only C# with Smart Device Programmability and this would be the same as a single language product. This was a real missed opportunity.

While I can understand the issues with an SDK product there is still no decent technical argument to justify the lack of SDP in single language products. :cry:

[Andy Sjostrom]

I don't understand how you can say that we disagree. I agree that it would be great to have .NET CF support in single language products.

Therefore I don't think there would be significant test resources required to test either VB.NET or C# .NET because they are essentially a custom installation of Visual Studio with only a single language installed.

This is where we might disagree. The basis of this potential disagreement is how we, you and I, guess the amount of work it would take to actually break out different SKUs and setup programs from VS.NET. Knowing a little bit about Microsoft testing, I guess that the efforts are substantial from the perspective the team was in a year ago. You guess differently. Would be great if David could respond here too! :D

[Kevin Daly]

I have been to many face-to-face meetings with .NET Compact Framework product managers to know that David's "resource constraint" argument is true. The team fought hard against deadlines, feature requests, footprint constraints, performance optimizations and so on.
I agree with you about the "resource constraint" argument. It's only to be expected.
Actually, I'm quite upbeat about this: I think it would be unreasonable of us to ask for another completely free full development environment (so I'm not worried about not getting that), while I now think there is every chance that we will eventually get what is reasonable (Compact Framework development tools included in the single language versions).
It's reasonable to expect that by that time (assuming it happens) new Pocket PCs will all be shipping with the CF pre-installed, which should add some momentum to the software market, as will the proliferation and increased acceptance of XML web services (I personally regard web services + smart devices as a killer combination. There are real opportunities there).

[Peter Foot]

I don't understand how you can say that we disagree. I agree that it would be great to have .NET CF support in single language products

I disagree that the issue of single language SKUs is related to the availability of an SDK. The VB.NET and VC# products are just members of the Visual Studio family (VS .NET Enerprise for example is simply VC#, VB.NET, Crystal Reports, VC++ and various other tools) an SDK is an entirely different beast to produce, document and support.

The basis of this potential disagreement is how we, you and I, guess the amount of work it would take to actually break out different SKUs and setup programs from VS.NET. Knowing a little bit about Microsoft testing, I guess that the efforts are substantial from the perspective the team was in a year ago. You guess differently. Would be great if David could respond here too! :D

Well I've based my estimate on the fact that regardless of Smart Device functionality there will be a C# single language product (and VB.NET of course). There is a certain level of testing required to test this as a separate package. The additional test case scenarios for Smart Device Programmability would be in the big picture not a great outlay, and afterall the test cases are already written for the full VS package, C# would merely be a subset of the full package. The same goes for VB of course.

Additional resources are required to do additional work of course but Microsoft are certainly capable of putting these resources in place if they really want to. If Mobility is important to them they will need to get all aspects of the developer community on board.

I think this is a fault not on the developers part who I know have worked very hard on producing an excellent product, I think it is primarily a marketing mistake, .NET CF has been marketed at the enterprise from the beginning. MS would have no interest in selling a single language product to an enterprise who would happily buy the top of the range VS suite.

Obviously all this is purely academic as VS is shipping on the 24th so we won't see any change to the products at this late stage. However it would be practical to produce an SDP package to add-on to C# and VB packages to follow release. If Microsoft need resources to create such a package they know where they can contact me

[Andy Sjostrom]

The additional test case scenarios for Smart Device Programmability would be in the big picture not a great outlay, and afterall the test cases are already written for the full VS package, C# would merely be a subset of the full package. The same goes for VB of course.

We clearly disagree in terms of what we guess / assume. The words "not a great outlay" and "merely" indicate that you believe that the efforts would not be significant. I guess / assume that they would be. At least in the light of how things were around the .NET CF team when all this was decided. I think they did the right thing: I'd rather have the tools now and get more later than wait another x months and get it later. In the end we both want the same thing, but I don't mind moving forward in smaller steps if that means that I can realize benefits as we move along.

[Peter Foot]

The additional test case scenarios for Smart Device Programmability would be in the big picture not a great outlay, and afterall the test cases are already written for the full VS package, C# would merely be a subset of the full package. The same goes for VB of course.

We clearly disagree in terms of what we guess / assume. The words "not a great outlay" and "merely" indicate that you believe that the efforts would not be significant. I guess / assume that they would be.

My "guess/assumption" is based on both the architecture of Visual Studio and previous test and integration experience on complex software projects though admittedly not related to desktop or device development.

Visual Studio is a huge project when taken as a whole. It is also a modular package, a user with even the full Enterprise package can choose to only install the VB product and not include any of the enterprise apps and tools. So if you are suggesting that the current SDP functionality has not been tested in such scenarios then we should all be very worried. A full regression test on a single language SKU is perfectly feasable.

Single language products are variations of the install package, so I stand by the fact that in the overall scheme of Visual Studio Studio giving the two main languages the functionality that is available to them would not significantly add to the workload. As I've said before this appears to be a marketing decision not a technical one.

However I agree with your idea of stepping the functionality. I think once the release of VS is over they should make an effort to plug an SDP add-in to the single language products, it doesn't have to be free, people will pay for quality development tools that add value but it needs to be aimed at the group of developers who can't consider VS 2003 Pro or Enterprise.

[Scott R]

I just spotted this article and I'm happy to see that pretty much everything that I would have said has already been said. I think Peter's comments sum it up nicely:
I disagree that the issue of single language SKUs is related to the availability of an SDK. The VB.NET and VC# products are just members of the Visual Studio family (VS .NET Enerprise for example is simply VC#, VB.NET, Crystal Reports, VC++ and various other tools) an SDK is an entirely different beast to produce, document and support.
Is this or is this not true? If the Visual Studio .NET package is more than just a bundled set of the standalone products (plus the extra pieces that can only be had by buying VS.NET), then I see no reason why the CF couldn't have just as easily been bundled with the standalone products. From where I'm sitting, this appears to clearly be a marketing decision. If that's the case, I'd have a lot more respect for them if they'd just come out and say it, instead of skirting around the issue.

Scott

[Mobile Bob]

...although I still don't understand why the device development tools can't be provided with all versions of VS.NET 2003...

Which version(s) of Visual Studio.NET 2003 do not include the device development tools?

[Peter Foot]

...although I still don't understand why the device development tools can't be provided with all versions of VS.NET 2003...

Which version(s) of Visual Studio.NET 2003 do not include the device development tools?

Visual C# and Visual Basic .NET individual products do not have device development.

Visual Studio Professional, Enterprise Architect and Enterprise Developer DO feature device development.

I have not seen any formal announcement about other versions e.g. Academic releases etc...