Since the announcement of our SP1 release yesterday, there’s been a variety of community feedback. Some in the press, some on blogs and some in email. I got one of those emails this morning and decided to write a few of my thoughts to share my perspective on the issues raised. It was then suggested I make a blog post out of it, so here it goes. This is not an official Microsoft position but just some ramblings from a random person…
Time to ship
There’s been some feedback that Soma’s announcement of “3-4 months to ship SP1” seemed excessive. Shipping an SP is a big effort for us. It might seem like it shouldn’t be, but it is. In particular, this SP is really large. There are a lot of bug fixes and a pretty significant sprinkling of new features. Further the product is big and signing off on it is a very involved process that requires each of the 30 or more teams to do a great deal of work – extensive testing across a broad matrix of platforms and software configurations, security reviews, inappropriate terminology scans (urban legend says that a few years ago someone in Microsoft got put in jail because some product referred to some unnamed island as a country. I don’t know if it’s true or not but that’s how seriously we take it whether or not it is), and much more.
When we think about the schedule for this kind of thing, we generally like to give about 1 month for the Beta – in order for people to have enough time to install it, try it out and report any issues they have. There’s then some time for us to fix any issues that were reported, then patch production (which takes about a week – remember, we have a TON of different SKUs and languages), followed by a final test pass (which takes about 2 weeks). When the bits are finally compiled and tested, there’s another week or two of production that ultimately places them on a download site for people to access.
It’s a lot of things. Most of them don’t take all that long but when you add it up, it takes a while. As far as broadcasting dates, we’re generally loath to do that because things change and people get mad at us when we don’t do what we said. As a result, when we do give dates, we tend to pad them a little bit for the unexpected. If everything goes according to plan, then I expect the schedule will be on the short end of Soma’s range. If something goes awry, it might not be.
We are making a concerted effort over the next 6 months to a year to look at the processes we use to produce service packs and optimize them. Personally, I am an advocate of shipping an SP for the last major released version every 6-9 months. Doing this would require us reducing the time to ship an SP from the approximately 6 months it takes now to probably 3 months or so. It’s something we are looking into.
I think we are seeing some reaction to this on all fronts. People raise the question of whether or not VS’s stance on Vista support for its various versions signals a problem with Vista compatibility. I do not believe so. VERY few applications are like VS. The problems VS has running on Vista generally aren’t with “normal” application like code. The single biggest source of issues is the area surrounding the debugger. Not many applications are that invasive. Vista made a lot of changes to really try to lock down on security to further reduce vulnerability. Those kinds of changes really run contrary to the kinds of invasive things a debugger needs to do. Innovation requires change and change results in work. The Windows team goes to UNBELIEVABLE lengths to keep compatibility with previous applications and well beyond what you might expect.
Like you, we have resource constraints. It might look like Microsoft is a huge company with infinite resources but, unfortunately, it’s not. We are just as constrained as everyone else in the world as to how we invest our time and money. I can assure you we have spent a lot management time wringing our hands over what the right thing to do here is. All work we do comes at an opportunity cost. For example, if we go back and make VS2002 work on Vista, we have to trade that off against not making progress on Orcas. Ultimately, we balanced all of these trade-offs and came up with this plan. The plan is to support our run time environments on Vista and to support VB6, VS2005, Orcas and all future versions. Would it be good to support more? Yes. Is it worth the opportunity cost? We think it isn’t.
Of all the things Microsoft is and isn’t, we are very responsive to customer feedback. We made the decision that we think is in the best interest of our customers. If customers come back broadly and tell us they disagree, then we’ll reassess that decision. All of our goals here are the same – making everyone as productive and successful as possible. I don’t mean to sound patronizing here – I really believe it.