From the evangelist den...
As i step into the new role of a Developer Evangelist at Microsoft, a few things that i will be trying to do more often:
1) Update this blog frequently (based on the speed of useful thoughts coming in....)
2) Try to speak about stuff that is not spoken elsewhere (this is going to be difficult)
3) Try and speak about stuff from both a customer's perspective and from a product development perspective (an unbiased effort to bridge the gap)
So to begin with - let me give you some back ground. In my previous role as a technical lead on the VC++/C# support team, during the past two years, i interacted with or looked into issues from almost like 2500+ developers. Some were more or less like misunderstanding of a functionality or feature or just unawareness about how it could be done differently or better and some were like serious bugs in our product. While these are something that can be addressed - there is a category of issues that usually goes undealt and is a cause of major dissatisfaction to our customers - this category largely deals with design decision that were taken by the products team after a lot of thought and analysis, but due so some conflicting reasons prove to be major issues for a certain section of developers. This third category is one on which i will be speaking more often - to try and get the messages from both sides across to each other and bridge the gap between the customer and the product. Example of this third category includes issues like:
1) Why can't i pass objects across c-runtime (CRT) boundaries.
2) Why is the garbage collector (GC) not working as i want it to.
3) Why can't i unload the CLR once it's loaded inside the process
4) Why was Side-by-Side installation of the libraries chosen as a deployment strategy
and a lot of similar kind of issues. My intent is not to solve issues here (although i will not desist from sharing my 2 cents of knowledge if i can) as that can be taken care of by the support group, but rather focus on bringing clarity and helping developers understand the "stuff" from a product development perspective. Also, the other way round - i want my blog to serve as a medium of collecting user feedback on development technologies and products, so that i can pass them to the product teams. Do feel free to ask questions that are troubling you the most about Microsoft Products - primarily Visual Studio, VC++, C#, .Net Framework and related things.
I am presently focusing on “Orcas” and have just finished delivering a webcast series on the same. I was thrilled by the response almost like 400 people attended all the sessions combined. It is nice to see so much interest around a product that is still in the CTP. I would love to hear from people who are evaluating Orcas and have any feedback, doubts or comments. Also before i address today's question, i wanted to mention that we are holding the biggest technology show in India at Mumbai from 13th to 16th June - TechMela - it is TechEd, Mobile and Embedded Developer Conference, MIX, and IT Professionals' Conference all combined together! I am going to be speaking there and it's going to be exciting! Do come and visit us - it would be a pleasure to know from you - what you want from the products!
So finally today's question:
1) Why Orcas? Why so soon? We just had Whidbey (VS 2005) about less than 2 years ago....
A common complain our customers often have is that we release products too soon in a rush to provide more features and concentrate less on fixing problems or improving the existing feature set. Now, this may be partially correct but i feel that the way it is understood is wrong.
Product development has its own dynamics, especially for a development tool like Visual Studio. This is a tool that is used by developers to develop applications so if it does not keep pace with the development of technology in other areas - e.g. the platform, it is no longer going to be a choice for the customers. So once, we released Vista and other products like Office 2007, there was an urgent need for a tool that would allow developers to utilize all the new capabilities - the entire functionality set and at the same time do it as easily as they are used to - using a tool like Visual Studio - hence even though improving the existing features is important, keeping the tool up to date is important. After all you would not use a hammer instead of dynamite to tear a building down!
The second part of the concern is that - we do not focus on fixing bugs - this is simply not true. Infact from my understanding of the DevDiv - they are very focused on fixing issues faced by the customers. But not everything has the same priority and many a times things may just be left because more high priority things are there.