Welcome to the VS SDK


As my first blog, I thought I would spend time discussing the Visual Studio SDK. I want to cover how it came to replace the VSIP SDK and what the implications are, how the Visual Studio SDK team is organized, and what our plans are.


Historically, the VSIP SDK was the SDK associated with the VSIP marketing program. The VSIP marketing program was a fee-based program directed at 3rd party Tools ISVs who wanted to extend VS, generally language vendors, development tool vendors ( like SCC tools, code analysis tools, etc ), and component vendors.


Starting in December 2004, the 3rd party ecosystem around Visual Studio was evaluated and several structural problems around the VSIP SDK were identified:


   1) The SDK was tied to and limited by the Visual Studio release dates. It’s really the second part that is the main issue as of course an SDK needs to release when the platform releases. To really serve the customers, though, more often releases were required. Customers should not be required to wait years for SDK content refreshes. Whenever there is new and valuable content, the SDK should be updated.


   2) VSIP SDK content was not high-quality. The samples and documentation content had aggregated organically over time without detailed long-term planning. While some of the samples were valuable and useful, they did not follow a consistent style or convention. Similarly, the documentation reflected older organizations and newer content felt “shoe-horned” in.


   3) VSIP SDK was too focused on Visual Studio Package Integration. As Visual Studio added the Team System SKUs for the Visual Studio 2005 release, additional integration points like SDM schemas, VSTS extensibility points, DSL toolkit, and more have expanded the meaning of extensibility beyond IDE package integration.


Taking a hard look at this data, the charter for the SDK team was expanded to:


   1) include out-of-band releases at a frequency that delivers value to the developer customer.


   2) redesign and rearchitect the SDK and how it was organized and developed.


   3) provide an umbrella for Developer Division extensibility toolkits outside the original scope of Visual Studio package integration.


 


I was hired in March 2005 to be Program Manager for the new Visual Studio SDK as part of that expanded charter.  One thing I should make clear, the VSIP marketing program continues to exist and move forward. Its only the SDK that has changed. During April, the SDK team began reorganizing itself using the SCRUM agile methodology. SCRUM is very cool, and I cant go into enough depth here to give it its just rewards. Lets just say SCRUM works around 1)short bursts that result in shippable work; 2)with daily “stand-ups” where everyone discusses what they have completed, what they work on next, and if they are blocked; 3)and uses a SCRUM-master to keep things organized and a product owner to validate the plans as providing customer value.


 


First we decided on a ship schedule. We decided to ship 3 times a year, roughly coinciding with major Microsoft events; such as VS Live in the Feb timeframe, Tech-Ed in the June timeframe, and PDC in the Oct timeframe. PDC doesn’t happen every year, but this schedule gives us the opportunity to get out in front of the community with new bits on a regular basis.


Next, we developed a plan to span from May to RTM in November, with a goal of shipping a high-quality SDK for RTM, using monthly sprints to reach parity with the VSIP SDK content and then pass it in terms of quality content. We set up monthly sprints with themes and milestones as follows:


   May  : Infrastructure Development


   June : Parity with the VSIP SDK


   July : Content Sprint 1


   Aug  : Content Sprint 2


   Sept : Content Sprint 3


   Oct  : Release Sprint


   Nov  : RTM


 


The “Infrastructure Sprint” allowed us to invest in fundamentals to ensure our development and release practices met internal guidelines and enabled us to reach our end goal. During the “Parity Sprint” the team decided to use the approach of including the existing samples in an “Archive” folder in the new Visual Studio SDK as the best approach to reach parity. This meant developers depending on existing samples were not left out to dry, but that new developers were given the indication as to the quality of the existing sample set. The goals for the content sprints were to tackle the Pri 0 scenarios ( Basic Package, Services, ToolWindow, MenusAndCommands ) and to build both native and managed samples for those scenarios using new coding and style standards. In addition, the SDK needed a new setup, we wanted to ship Unit Tests were we could, and were looking for low-hanging fruit in terms of samples that showed interesting but lower priority scenarios.


 


Finally, we worked with partner teams to integrate their bits in a natural fashion. This included partner teams that were already in the SDK ( SCC, Debugger, VS Data, Help Integration ) as well as new partner teams like SDM and TFS. The organization of the partner team bits as well as the core functionality is now organized into large integration buckets. All things about the IDE are included in the Visual Studio Integration node. TFS Integration is its own node. Future partner team content like VSTA will also get its own node, whereas DSL content which is IDE focused will land under the Visual Studio Integration node like SDM.


 


From the SDK readme file, you can see what we accomplished. We hit the main goals, and we added several usability enhancements, 3 new examples, the source to the Package.Project portion of the MPF, and more.  All in all it was a busy but rewarding 6 months and we hope you enjoy and appreciate our efforts on your behalf to improve the Visual Studio Integration experience.


 


 


 


Comments (5)

  1. vrapp says:

    This is what I don’t follow: "It was a conscious design decision of the studio to load the sliders so that, on day one, no one can run the sim at full slider levels. We did that so the sim will still have life in it three years from now. (…) It will be that way in FS11, and it was that way in FS9"

    I don’t understand, why would the sim not have life in 3 years if it was working OK with full settings from day one? would colors pale in 3 years? would small terrain details wear?

    Why not to give me more for my money today?

    You want the game to improve for the user with the time? Sorry, I don’t think it’s realistic. Users who seek new experience in the game, in those three years will buy then-new version of the sim anyway. I personally don’t recall myself increasing the settings of an old game after years of using it. It seems to me that those details in 99% are the hidden treasure that will never be uncovered.

    And yet another consideration. There’s a risk that whatever hardware and matching o/s will come in in 3 years, they will be for yet-unknown reasons incompatible with today’s game.

    And, besides everything else, I think this step is merely anti-marketing and bad business decision for Microsoft – speaking of the future sales of future releases.

  2. vrapp says:

    (sorry, wrong place – I now reposted in the page where the cited phrase appears)

  3. beemer says:

    In 1996. after spending alomost 4 grand on my firsr pc package, I bought a Formula One racing simulator.  It was called Grand Prix 2, from Microprose.  My new 200 mhz processor was the high end at the time.  The game was released about a year earlier.  There were wonderful free add-ons from around the world.  But the F1 community wrestled the sim for higher settings for years.  Even without mods, it bogged down on most people.  I was only able to run qualifying laps at around 75% of full settings.  A 16 car race, at half-baked settings made Monaco look worse than my little college town.  I remember talking to Microprose and being told it would take a "supercomputer" to race at full settings.  They said the game was built for future pc’s.  Well, I never did see that game run to it’s potential.  By the time pc’s were out that ran it, this dos game was outdated by Ubisoft and others.  Because of my experience, I decided to switch to  Apple in 2000.  I figured that owning a Mac would keep me from experimenting with games that tickled my fancy with screenshots.  It worked.  I didn’t care about games for a good long time.  But FSX is here and it has gotten my juices flowing again.  I am itching to switch to a pc and try it.  The question for me is, am I going to be wrestling a losing battle for performance with FSX for a few years like GP2?  From what I gather, unless I wait a year or two for specs to catch up, that’s exactly what’s going to happen.  By that time, as vrapp warns in the last post, there could be a new set of circumstances.  

    Anyway Phil, I just wanted to express my thoughts as a potential customer.  FSX is a wonderful sim.  I’m anxious to get started,.  But I can’t  bring myself to settle for the medium settings, knowing that the scenic "Monaco" is somewhere in the future, and another pc change away.

    p.s.   I looked at the new scenery for X-Plane.  They have some screenshots of cities that are more toward the impressionist side.  They look okay from my view, and provide realistic city density. I don’t like X Plane partly because it seems disorganized as far as standards and objectives.  But perhaps you could "skeletonize" your buildings for the lmedium settings crowd.  Most people seem to have trouble flying over cities at high settings.  Just a thought from a non tech guy.

    Thanks again for the blog, and for your time.  

    Regards

    Ed

  4. peakoilishere says:

    Phil,

    You mentioned in an earlier post a while back that :

    "It was a conscious design decision of the studio to load the sliders so that, on day one, no one can run the sim at full slider levels. We did that so the sim will still have life in it three years from now. (…) It will be that way in FS11, and it was that way in FS9"

    In general, I agree that technology in and of itself is inherently a double-edged sword, so to speak. You can be state of the art today but tomorrow you may be a dinosaur if you stand still and don’t progress or catch up… That’s just the nature of technology and ‘progress’. I’m someone who always likes to get the latests and greatest (aren’t we all?) but paradoxically and perhaps even contradictorily, at the same time I want or hope for each product or software I invest my time and energy into to last as long as possible, (I’m nostalgic and reminiscent type) to remain relevant and not become obsolete quickly. In short, I want the newest but also I want my product to be as ‘future-proofed’ as possible… Therefore the conflict of technology and headaches of perpetual change and readjustment/adaptation.

    Specifically, how this applies to FSX and PREVIOUS versions of Microsoft Flight Simulators that have been

    ‘sunset’:

    I bought FS9 (2004) in 2004. So three years later right now I can pretty much run all my sliders on full. Therefore according to your studio my product is still valid/ or at least still have ‘life’ so to speak. Then why should I upgrade to FSX right now? I am not bashing anyone or any company, but don’t you see the catch-22 and circular logic of your comment above? If your team does it so each game can only be maximally enjoyed after 3-4 years, and yet you also come out with a newer much more hardware intensive version about every 2-3 years, then whats the point?

    Either I should skip every other release of Flight Simulator (that something you would recommend for politically correct reasons) or else I will never be able to enjoy the benefit and conscious design decision of your team since they always make FS impossible to max out until Microsoft has come out with a new version and sunsets the current version….

    If a product was designed to still have ‘life’ by the developers after 3 years, why should I upgrade to a newer version every 2-3 years? If the developers know they will come out with a newer verion every 2-3 years, why make it so that the slider can only be maxed out AFTER 3 years? Why not just give us what we want to begin with, cause surely I can say without a doubt every time a new product comes out no one at Microsoft is telling us we should now enjoy the older on at MAX slider, Microsoft team each time overtly adveristings and pressures its customer base to ‘switch’ /upgrade / experience a new game, etc…

    You can’t have it both ways Phil. Since Microsoft pretty much expects or at least really hopes for all its customer base to upgrade to newer versions and since it realeases newer versions just around or even sooner than the amount of time it takes the current version to be able to be played at maxed out sliders, then its philosophy of ""It was a conscious design decision of the studio to load the sliders so that, on day one, no one can run the sim at full slider levels. We did that so the sim will still have life in it three years from now."" is made INVALID, and thus I see potentially a more cynical and ulterior motive to purposely designing Flight Simulator to never be able to be fully enjoyed until it is made obsolete already. (and in Microsoft terms, obsolete pretty much means when we get the newer version on the horizon)

    Please I would like your honest thoughts about this…

    Thanks

  5. Phil Taylor says:

    Peak

    You mean a later post. This post was Nov 2005, the post you reference was Nov 2006.

    While there is life still in FS9, true, its getting shorter all the time. What is possible with FSX is just getting started, and in another year that question will answer itself. Note, there is always a "change over" period, for any software. And its up to each individual to decide when to change over. You can see what you want in that, but its just part of the normal cycle.

    With that said, and with the sliders loaded the way they are for a reason – we still had performance issues that required SP1 to address so that we could scale as the hardware got better. The DX10 patch will help with that as well. Making sure the performance will scale well with new hw is something we will be more intentional about moving forward.