Everything you want to know about Visual Studio ALM and Farming
Brian Harry is a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server. Learn more about Brian.
More videos »
Sorry I've been away a while. It's been almost 2 weeks since I've posted anything of much interest. It's been crazy trying to get so many things finished up by the end of the year and I just haven't had time to think straight. I've been trying to figure out what I was going to talk about next now that I've pretty much spilled the beans on everything we're doing for Orcas :) I figure it's best to just pick something I'm passionate about.
I'm passionate about delivering value as early and as often as we can. I wanted to share some thoughts with you and solicit some feedback. Don't take anything I'm going to say here as official Microsoft policy or a statement of direction for DevDiv or anything of the sort. Take it as the ramblings of someone who thinks about this stuff a lot. Also, these comments are mostly focused on what I think we should do with Visual Studio. For a variety of reasons the .NET Framework will have some different constraints.
Over the past several months you've seen a few initiatives kicked off to help improve transparency and value. Among them are:
These are all good steps but they don't fall into a comprehensive plan for how we deliver value and when. I've been thinking a lot about it lately and proposing a new model to people. The new model I have in my head looks something like this. It's a bit simplified to avoid this mail getting too long and don't confuse what I'm describing that's in my head with what we do today.
Major Releases - These are what you think of as VS releases today (VS2002, VS2003, VS2005, ...). They are developed a fairly regular cadence with a target interval of something like 24 months. They contain sweeping improvements and in many cases "Revolutionary" advancements (like .NET, WCF, WPF, Linq, etc). They are the "big bang" and are designed to make quantum improvements in the lives of developers.
Minor Releases - Minor releases would be small releases that are a combination of bug fixes and features. I think of them as an evolution of and a replacement for service packs. I'm thinking we should target having them every 6 - 9 months. They would be pure "evolution". The goal of them is to take the current feature set and just make it better - fix dissatisfiers, address bugs, add complimentary features (like FolderDiff and Annotate that we released as Power Toys for TFS), etc. Minor releases would have an extremely high compatibility bar. The goal would be for you to have no reason not move forward - just pure goodness: no disruption. I'm thinking they would be "free" downloads but would prereq the last major release (you've got to have some motivation to move forward and pay us money :)) Like service packs, minor releases would be tied to the servicing lifetime of the Major release they target.
Off cycle - These would be releases of varying size and scope that are released "off the train". They could take the form of something unsupported like the Power Toys. Or something "partially supported" like the TFS MSSCCI provider (I won't derail into a conversation about "levels of support" - that probably warrants another conversation). Other things that fall in this bucket are off cycle releases like the Ajax tool kit, etc. Off cycle releases provide a lower overhead opportunity for individual product groups to delvier value to leading edge technology adopters on a more frequent and/or more irregular basis without having to coordinate across all of VS. The expectation would be that many/most off cycle releases would ultimately be rolled into a major or minor release but not all. It would depend on the situation.
CTPs & Specs - Community Technology Previews and Spec Previews would continue to be a valuable way to preview what it coming in Major, Minor (and in some cases) off cycle releases.
Hot Fixes - We would continue to pursue the effort we currently have underway of making all hot fixes available for browsing and download, enabling you to find available fixes as quickly as possible.
Well, that's the 10,000 foot view of what I'm thinking. What do you think? It doesn't come without costs. Major releases would become somewhat smaller increments than they are today because some of the feature would have come out in preceding Minor releases. There's a ton of logistical issues we'd have to address internally to reduce the cost of producing a release and likely, in the short term, there would be an overall cost in the additional release overhead that I'd hope we could reduce over time with practice and tooling. This would mean an end to service packs as we know them today as pure bug fix delivery mechanisms. Is that OK?
Again, please don't get me in trouble by going around and telling people "Brian said DevDiv is ...". It's just me musing. If everyone likes the ideas, they may influence where we go in the future. If everyone hates them, they'll die on the vine :)
What do you think?