Measuring the scale of a release

Thanks for all the feedback that we have been getting. That much of it is positive is certainly appreciated. I’ve been answering mails as best I can and along with members of the team we’ve been having the discussion in the comments. Everyone has done a great job sharing their views on specifics, wishes, and requests. I love getting these mails and reading the comments. It is fantastic. I just want to make sure folks know I can’t answer each one! What we are going to do is look to the emails and comments as a way of suggesting posts we should write.  The team overall appreciate the warm reception from all those that have joined us--we know we have lots of energetic discussions ahead of us and we're genuinely happy to start.

With this post, I am hoping to continue the dialog on the way we think “inside the Win7 team” so to speak—in a sense this is about expanding the team a bit and bringing you into some more of the discussions we have about planning a release. This conversation about major or minor releases is very much like the one I have with my boss as we start planning :-)

When we started planning the release, the first thing some might think we have to decide is if Windows 7 (client) would be a “major release” or not. I put that in quotes because it turns out this isn’t really something you decide nor is it something with a single answer. The magnitude of a release is as much about your perspective on the features as it is about the features themselves. One could even ask if being declared a major release is a compliment or not. As engineers planning a product we decide up front the percentage of our development team will that work on the release and the extent of our schedule—with the result in hand customers each decide for themselves if the release is “major”, though of course we like to have an opinion. On the server blog we talked about the schedule and we shared our opinion of the scale of the releases of Windows 7 client and server.

Our goal is about building an awesome release of Windows 7.

Across all customers, there is always a view that a major release is one that has features that are really the ones for me. A minor release is one that doesn’t have anything for me. It should then be pretty easy to plan a major release—just make sure it exactly the right features for everyone (and given the focus on performance, it can’t have any extra features, even if other people want them)! As engineers we all know such a design process is really impossible, especially because more often than not any two customers can be found to want exactly opposite features. In fact as I type this I received sequential emails one saying “[N]obody cares about touch screen nonsense” and the other saying “[Win7 needs] more advanced/robust ‘touch’ features”. When you just get unstructured and unsolicited input you see these opposites quite a bit. I’m sure folks are noticing this on the blog comments as well.

Let’s explore the spectrum of release magnitude across a couple of (but not all) different types of customers: end-users, developers, partners, IT professionals, and influentials.

End-users are generally the most straight-forward in terms of deciding how big a release is going to be. For an end-user a release is a big deal if they want to go out and buy an upgrade or buy a new PC. We could call that a major release. Seems simple enough and a major release is good for everyone. On the other hand, one could also imagine that a release is really cool and people want to buy it, but they also want to use their existing PC and the release requires more memory, updated drivers that might not be available, or maybe some specific hardware to be fully realized. Then it seems that a major release goes from a positive to a bit of an under-taking and thus loses some of its luster. Of course we all know that what folks really want is all the things they want that runs on the hardware they want—then that is a great product to get (whether it is major or not).

Developers look at a release through a different lens. Obviously for developers a release is a major one if there are new APIs and capabilities to take advantage of in their software—again straight-forward enough. It could also be the case that a previous release had a lot of new APIs and folks are just getting familiar with using them and so what they really want is to round out the APIs and maybe improve performance. So one might suspect that the first release is a major release and the second type is a minor release. But if you look at the history of software products, it is often these “minor” releases that themselves become the major releases – Windows 3.1, Office 4.2, or even Windows XP SP2. In each of these cases, the target for developers became the “minor” release but in the eyes of the market that was the “major” release. The reason developers want to use new APIs is to differentiate their products or focus their energies on domain expertise they bring to the table, not just call new APIs for the sake of calling them. In that sense, a release might be a major one if it just happens to free up enough time for an ISV that they bet on the new APIs because they can focus on some things that are a major deal to them.

Partners represent the broad set of folks who create PCs, hardware, and the infrastructure we think of as the ecosystem that Windows is part of. Partners tend to think about a major release in terms of the opportunity it creates and thus a major release might be one with a lot of change and thus it affords the opportunity to provide new hardware and infrastructure to customers. On the other hand, incompatibilities with the past might be viewed in a less than positive light if it means a partner needs to stop moving forward and revisit past work to bring it up to the required compatibility with a new release of Windows. If they choose, for any number of reasons, not to do that work then the release might be viewed as a minor one because of the lack of ecosystem support. So again we see that a big change can be viewed through the lens of a major or a minor release.

IT professionals are often characterized as conservative by nature and thus take a conservative view of change. Due to the business focused nature of the role, the evaluation of any software product is going to take place in the context of a return on investment. So for an IT professional a major release would be one that delivers significant business value. This business value could be defined as a major investment in deployment and management of the software for example. Yet for end-users or developers, these very same features might not even be interesting let alone worthy of being a major or minor release.

Influentials are all the folks who are in the business of providing advice, analysis, and viewpoints on the software we make. These folks often look at releases through the metric of “change”. Big changes equal major release. A big change can be a “re-architecture” as we saw in the transition from Windows 9x to Windows 2000—even though these products looked the same there was tons of change to talk about under the hood. So for reviewers and analysts it was definitely a major release. Big changes can also be big changes in the user-interface because that drives lots of discussion and it is easy to show all the change. Yet for each of these, this definition of major can also be viewed as a less than positive attribute. Re-architecture means potential incompatibilities. New user-interface can mean learning and moving from the familiar.

We’ve seen a lot of comments and I have gotten a lot of email talking about re-architecting Windows as a symbol of a major release. We’ve also gotten a lot of feedback about how a major release is one that breaks with supporting the past. If I could generalize, folks are usually implying that if we do things like that then a number of other major benefits will follow—re-architecting leads to better performance, breaking with the past leads to using less memory. It is always tricky to debate those points because we are comparing a known state to a state where we fix all the things we know to fix, but we don’t yet know what we might introduce, break, or otherwise not fix. So rather than define a major release relative to the implementation, I think it makes sense define the success of the release relative to the benefits of whatever implementation is chosen.  We will definitely continue to pick up on this part of the discussion--there's a lot of dialog to have.

The key is always a balance. We can have big changes for all customers if we prepare all the necessary folks to work through the change. We can have small changes have a big impact if they are the right changes at the right time, and those will get recorded over time as a major release.

We’ve talked about the timing and the way we structure the team, so you have a sense for the “inputs” into the project. If we listened well and focused our efforts correctly, then each type of customers will find things that make the product worthwhile. And if we do our job at effectively communicating the product, then even the things that could be “problems” are seen in the broader context of an ecosystem where everyone collectively benefits when a few people benefit significantly.

From our perspective, we dedicated our full engineering team and a significant schedule to building the Windows 7 client OS. That makes it a major undertaking by any definition. We intend for Windows 7 to be an awesome release.

I hope this helped to see that perspective is everything when it comes to deciding how big a release is for each type of customer.

--Steven