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.