These postings are provided "AS IS" with no warranties, and confer no rights. Use of included code samples are subject to the terms specified at Microsoft -
Notes on comments.
Welcome to our blog dedicated to the engineering of Microsoft Windows 7
Welcome to our first post on a new blog from Microsoft—the Engineering Windows 7 blog, or E7 for short. E7 is hosted by the two senior engineering managers for the Windows 7 product, Jon DeVaan and Steven Sinofsky. Jon and Steven, along with members of the engineering team will post, comment, and participate in this blog.
Beginning with this post together we are going to start looking forward towards the “Windows 7” project. We know there are tons of questions about the specifics of the project and strong desire to know what’s in store for the next major release of Windows. Believe us, we are just as excited to start talking about the release. Over the past 18 months since Windows Vista’s broad availability, the team has been hard at work creating the next Windows product.
The audience of enthusiasts, bloggers, and those that are the most passionate about Windows represent the folks we are dedicating this blog to. With this blog we’re opening up a two-way discussion about how we are making Windows 7. Windows has all the challenges of every large scale software project—picking features, designing them, developing them, and delivering them with high quality. Windows has an added challenge of doing so for an extraordinarily diverse set of customers. As a team and as individuals on the team we continue to be humbled by this responsibility.
We strongly believe that success for Windows 7 includes an open and honest, and two-way, discussion about how we balance all of these interests and deliver software on the scale of Windows. We promise and will deliver such a dialog with this blog.
Planning a product like Windows involves systematic learning from customers of all types. In terms of planning the release we’ve been working with a wide variety of customers and partners (PC makers, hardware developers, enterprise customers, developers, and more) since the start of the project. We also continue our broad consumer learning through telemetry (Customer Experience Improvement Program), usability studies, and more. One area this blog will soon explore is all the different ways we learn from customers and the marketplace that inform the release.
We have two significant events for developers and the overall ecosystem around Windows this fall. The Professional Developers Conference (PDC) on October 27 and the Windows Hardware Engineering Conference (WinHEC) the following week both represent the first venues where we will provide in-depth technical information about Windows 7. This blog will provide context over the next 2+ months with regular posts about the behind the scenes development of the release and continue through the release of the product.
In leading up to this blog we have seen a lot of discussion in blogs about what Microsoft might be trying to accomplish by maintaining a little bit more control over the communication around Windows 7 (some might say that this is a significant understatement). We, as a team, definitely learned some lessons about “disclosure” and how we can all too easily get ahead of ourselves in talking about features before our understanding of them is solid. Our intent with Windows 7 and the pre-release communication is to make sure that we have a reasonable degree of confidence in what we talk about when we do talk. Again, top of mind for us is the responsibility we feel to make sure we are not stressing priorities, churning resource allocations, or causing strategic confusion among the tens of thousands of partners and customers who care deeply and have much invested in the evolution of Windows.
Related to disclosure is the idea of how we make sure not to set expectations around the release that end up disappointing you—features that don’t make it, claims that don’t stick, or support we don’t provide. Starting from the first days of developing Windows 7, we have committed as a team to “promise and deliver”. That’s our goal—share with you what we’re going to get done, why we’re doing it, and deliver it with high quality and on time.
We’re excited about this blog. As active bloggers on Microsoft’s intranet we are both looking forward to turning our attention and blogging energies towards the community outside Microsoft. We know the ins and outs of blogging and expect to have fun, provide great information, and also make a few mistakes. We know we’ll misspeak or what we say will be heard differently than we intended. We’re not worried. All we ask is that we have a dialog based on mutual respect and the shared goal of making a great release of Windows 7.
Our intent is to post “regularly”. We’ll watch the comments and we will definitely participate both in comments and potentially in follow-up posts as required. We will make sure that members of the Windows 7 development team represent themselves as such as well. While we want to keep the dialog out in the open, please feel free to use email to firstname.lastname@example.org should you wish to. In particular, email is a good way to suggest topics we might have a chance to discuss on the blog.
With that, we conclude our welcome post and ask you to stay tuned and join us in this dialog about the engineering of Windows 7.
Steven and Jon
Please note the availability of this blog in several other languages via the links on the nav pane. These posts are also created by members of our development team and we welcome dialog on these sites as well. We will continue to expand the list in other languages based on feedback.
Ed. Note: This is our first post from a senior member of the development team. Allow me to introduce Michael Fortin who is one of Microsoft’s Distinguished Engineers and leads the Fundamentals feature team that is in our Core Operating System group. Michael leads performance and reliability efforts across the Windows platform. --Steven (PS: Be sure to visit www.microsoft.com/ie and try out the beta 2 release of Internet Explorer 8).
For Windows 7, we have a dedicated team focused on startup performance, but in reality the effort extends across the entire Windows division and beyond. Our many hardware and software partners are working closely with us and can rightly be considered an extension to the team.
Startup can be one of three experiences; boot, resume from sleep, or resume from hibernate. Although resume from sleep is the default, and often 2 to 5 seconds based on common hardware and standard software loads, this post is primarily about boot as that experience has been commented on frequently. For Windows 7, a top goal is to significantly increase the number of systems that experience very good boot times. In the lab, a very good system is one that boots in under 15 seconds.
For a PC to boot fast a number of tasks need to be performed efficiently and with a high degree of parallelism.
Because systems and configurations differ, boot times can vary significantly. This is verified by many lab results, but can also be seen in independent analysis, such as that conducted by Ed Bott. Sample data from Ed’s population of systems found that only 35% of boots took less than 30 seconds to give control to the user. Though Ed’s data is from a small population, his data is nicely in line with what we’re observing. Windows Vista SP1 data (below) also indicates that roughly 35% of systems boot in 30 seconds or less, 75% of systems boot in 50 seconds or less. The Vista SP1 data is real world telemetry data. It comes to us from the very large number of systems (millions) where users have chosen to send anonymous data to Microsoft via the Customer Experience Improvement Program.
From our perspective, too few systems consistently boot fast enough and we have to do much better. Obviously the systems that are greater than 60 seconds have something we need to dramatically improve—whether these are devices, networking, or software issues. As you can see there are some systems experiencing very long boot times. One of the things we see in the PC space is this variability of performance—variability arises from the variety of choices, and also the variety of quality of components of any given PC experience. There are also some system maintenance tasks that can contribute to long boot times. If a user opts to install a large software update, the actual updating of the system may occur during the next boot. Our metrics will capture these and unfortunately they can take minutes to complete. Regardless of the cause, a big part of the work we need to do as members of the PC ecosystem is address long boot times.
In both Ed’s sample and our telemetry data, boot time is meant to reflect when a machine is ready and responsive for the user. It includes logging in to the system and getting to a usable desktop. It is not a perfect metric, but one that does capture the vast majority of issues. On Windows 7 and Vista systems, the metric is captured automatically and stored in the system event log. Ed’s article covers this in depth.
We realize there are other perceptions that users deem as reflecting boot time, such as when the disk stops, when their apps are fully responsive, or when the start menu and desktop can be used. Also, “Post Boot” time (when applications in the Startup group run and some delayed services execute), the period before Windows boot is initiated, and BIOS time can be significant. In our efforts, we’ve not lost sight of what users consider being representative of boot.
Before discussing some of our Windows 7 efforts, we’d like to point out there is considerable engagement with our partners underway. In scanning dozens of systems, we’ve found plenty of opportunity for improvement and have made changes. Illustrating that, please consider the following data taken from a real system. As the system arrived to us, the off-the-shelf configuration had a ~45 second boot time. Performing a clean install of Vista SP1 on the same system produced a consistent ~23 second boot time. Of course, being a clean install, there were many fewer processes, services and a slightly different set of drivers (mostly the versions were different). However, we were able to take the off-the-shelf configuration and optimize it to produce a consistent boot time of ~21 seconds, ~2 seconds faster than the clean install because some driver/BIOS changes could be made in the optimized configuration.
For this same system, it is worth noting the resume from sleep time is approximately 2 seconds, achieving a nearly instant on experience. We do encourage users to choose sleep as an alternative to boot.
As an example Windows 7 effort, we are working very hard on system services. We aim to dramatically reduce them in number, as well as reduce their CPU, disk and memory demands. Our perspective on this is simple; if a service is not absolutely required, it shouldn’t be starting and a trigger should exist to handle rare conditions so that the service operates only then.
Of course, services exist to complete user experiences, even rare ones. Consider the case where a new keyboard, mouse or tablet HW is added to the system while it was off. If this new HW isn’t detected and drivers installed to make the HW work during startup, then the user may not be able to enter their credentials and log into the machine. For a given user, this may be a very rare or never encountered event. For a population of 100s of millions of users, this can happen frequently enough to warrant having mechanisms to support it. In Windows 7, we will support this scenario and many others with fewer auto start services because more comprehensive service trigger mechanisms have been created.
As noted above, device and driver initialization can be a significant contributor as well. In Windows 7, we’ve focused very hard on increasing parallelism of driver initialization. This increased parallelism decreases the likelihood that a few slower devices/drivers will impact the overall boot time.
In terms of reading files from the disk, Windows 7 has improvements in the “prefetching” logic and mechanisms. Prefetching was introduced way back in Windows XP. Since today’s disks have differing performance characteristics, the scheduling logic has undergone some changes to keep pace and stay efficient. As an example, we are evaluating the prefetcher on today’s solid state storage devices, going so far as to question if is required at all. Ultimately, analysis and performance metrics captured on an individual system will dynamically determine the extent to which we utilize the prefetcher.
There are improved diagnostic experiences in Windows 7 as well. We aim to quickly identify specific issues on individual systems, and provide help to assist in resolving the issues. We believe this is an appropriate way to inform users about some problems, such as having too many startup applications or the presence of lengthy domain-oriented logon scripts. As many users know, having too many startup applications is often the cause of long boot times. Few users, however, are familiar with implications of having problematic boot or logon scripts. In Windows XP, Vista and in Windows 7, the default behavior for Windows is to log the user into the desktop without waiting for potentially lengthy networking initialization or scripts to run. In corporate environments, however, it is possible for IT organizations to change the default and configure client systems to contact servers across the network. Unfortunately, when configuring clients to run scripts, domain administrators typically do so in a synchronous and blocking fashion. As a result, boot and logon can take minutes if networking timeouts or server authentication issues exist. Additionally, those scripts can run very expensive programs that consume CPU, disk and memory resources.
In addition to working on Windows 7 specific features and services, we are sharing tools, tests and data with our partners. The tools are available to enthusiasts as well. The tools we use internally to detect and correct boot issues are freely available today here as a part of the Windows Performance Toolkit. While not appropriate for most users, the tools are proving to be very helpful for some.
One of the topics we want to talk about in the future which we know has been written about a great deal and is the subject of many comments, is the role that additional software beyond the initial Windows installation plays in overall system performance. The sheer breadth and depth of software for Windows means that some software will not have the high quality one would hope, while the vast majority is quite good. Microsoft must continue to provide the tools for developers to write high performance software and the tools for end-users to identify the software on their system that might contribute to performance that isn’t meeting expectations. Windows itself must also continue to improve the defensive tactics it uses to isolate and inform the end-user about software that might contribute to poor performance.
Another potential future topic pertains to configuration changes a user can make on their own system. Many recommended changes aren’t helpful at all. For instance, we’ve found the vast majority of “registry tweak” recommendations to be bogus. Here’s one of my favorites. If you perform a Live search for “Enable Superfetch on XP”, you’ll get a large set of results. I can assure you, on Windows XP there is no Superfetch functionality and no value in setting the registry key noted on these sites. As with that myth, there are many recommendations pertaining to CPU scheduling, memory management and other configuration changes that aren’t helpful to system performance.
Startup is one topic on performance. As described in the previous post we want to continue the discussion around this topic. What are some of the elements you’d like to discuss more?
Thanks to everyone who provided comments and sent me mail. I definitely appreciate the discussion we have kicked off. There’s also a ton of energy in our hallways as this blog started. It seems like a good thing to do to start off is sort of an introduction to the Windows development team. This post provides an overview of the team that is represented by this blog.
Before diving into the main topic, let’s talk a bit more about what to expect from this blog. First a few words on the comments and emails I’ve received. I’ve received a ton—most of the weekend was spent reading emails and comments. There are definitely some themes. I would say by and large the reception has been very warm and we definitely appreciate that. The most frequent request was to discuss Windows performance and/or just “make Windows faster”. There’s a lot to this topic so we expect to talk about this quite a bit over the next months. There are many specific requests—often representing all possible sides of an issue such as some folks saying “please get rid of (or don’t do) <x>” and then other folks saying “whatever you do it is really important to keep (or do) <x>”. A big part of this blog for me personally is having the discussion about the multiple facets of any given issue. Even something that sounds as binary as performance proves to have many subtle elements. For example, some folks suggested that the best thing for boot performance is to not start anything until idle time and others suggested that the delay loading feels like it slows them down and still others have suggested that the best approach is to provide a startup manager that pushes everyone to choose what to start up. All of these have merit worth discussing and also demonstrate the subtlety and complexity of even the most straight forward request.
Second, much to the surprise of both Jon and I a number of folks questioned the “authenticity” of the post. A few even suggested that the posts are being “ghost written” or that this blog is some sort of ploy. I am typing this directly in Windows Live Writer and hitting publish. This blog is the real deal—typos, mistakes, and all. There’s no intermediary or vetting of the posts. We have folks on the team who will be contributing, but we’re not having any posts written by anyone other than who signs it. We will us one user name for all the posts since that keeps the blog security and ownership clear, but posts will be signed by the person that hit publish. (If I participate in the comments I will use my msdn name, steven_sinofsky.)
And third, what frequency should folks expect and when do we get to the “features of Windows 7”. When we wrote that we would post “regularly” we meant that we don’t have a schedule or calendar of posts and we don’t want to commit to an artificial frequency which generally seems inconsistent with blogging. We do expect to follow a pattern similar to what you have become familiar with on the IEBlog. FWIW, on my internal blog no one has yet accused me of not contributing enough. :-)
As we said in the introductory post we think it will be good to talk about the engineering of Windows 7 (the “how”) and the first step is establishing who the engineers are that do the engineering before we dive into the product itself (the “why” and “what”).
So let’s meet the team...
It is pretty easy to think of the Windows team as one group or one entity, and then occasionally one specific person comes to represent the team—perhaps she gave a talk at a conference, wrote a book or article folks become familiar with, or maybe he has a blog. Within Microsoft, the Windows product is really a product of the whole company with people across all the development groups contributing in some form or another. The Windows engineering team “proper” is jointly managed by Jon and me. Jon manages the core operating system, which is, among many things, the kernel, device infrastructure, networking, and the engineering tools and system (all of which are both client and server). I am part of the Windows client experience team which develops, among many things, the shell and desktop, graphics, and media support. One other significant part of the Windows product is the Windows Media Center which is a key contribution managed along with all of Microsoft’s TV support (IPTV, extenders, etc.).
There’s a lot to building an org structure for a large team, but the most important part is planning the work of the team. This planning is integral to realizing our goal of improving the overall consistency and “togetherness” for Windows 7. So rather than think of one big org, or two teams, we say that the Windows 7 engineering team is made up of about 25 different feature teams.
A feature team represents those that own a specific part of Windows 7—the code, features, quality, and overall development. The feature teams represent the locus of work and coordination across the team. This also provides a much more manageable size—feature teams fit in meeting spaces, can go to movies, and so on. On average a feature team is about 40 developers, but there are a variety of team sizes. There are two parts to a feature team: what the team works on and who makes up a team.
Windows 7’s feature teams sound a lot like parts of Windows with which you are familiar. Because of the platform elements of Windows we have many teams that have remained fairly constant over several releases, whereas some teams are brand new or represent relatively new areas composed of some new code and the code that formed the basis of the team. Some teams do lots of work for Server (such as the VM work) and some might have big deliverables outside of Windows 7 (such as Internet Explorer).
In general a feature team encompasses ownership of combination of architectural components and scenarios across Windows. “Feature” is always a tricky word since some folks think of feature as one element in the user-interface and others think of the feature as a traditional architectural component (say TCP/IP). Our approach is to balance across scenarios and architecture such that we have the right level of end-to-end coverage and the right parts of the architecture. One thing we do try to avoid is separating the “plumbing” from the “user interface” so that teams do have end-to-end ownership of work (as an example of that, “Find and Organize” builds both the indexer and the user interface for search). Some of the main feature teams for Windows 7 include (alphabetically):
I think most of these names are intuitive enough for the purposes of this post—as we post more the members of the team will identify which feature team they are on. This gives you an idea of the subsystems of Windows and how we break down a significant project into meaningful teams. Of course throughout the project we are coordinating and building features across teams. This is a matter of practice because you often want to engineer the code in one set of layers for efficiency and performance (say bottom up), but end-users might experience it across layers, and IT pros might want to manage a desktop from the top-down. I admit sometimes this is a little bit too much of an insider view as you can’t see where some interesting things “live”. For example, the tablet and inking functionality is in our User Interface Platform team along with speech recognition, multi-touch and accessibility. The reason for this is the architectural need to share the infrastructure for all mechanisms of “input” even if any one person might not cross all those layers. This way when we design the APIs for managing input, developers will see the benefits of all the modes of user interaction through one set of APIs.
The other aspect of our feature teams is the exact composition. A feature team represents three core engineering disciplines of software development engineers (sde or dev), software development engineers in test (sdet or test, sorry but I haven’t written a job description externally), and program managers (pm). Having all three of these engineering disciplines is a unique aspect of Microsoft that has even caught the attention of some researchers. In my old blog I described dev and pm which I linked to above (I still owe a similar post on SDET!).
The shortest version of these roles is dev is responsible for the architecture and code, pm is responsible for the feature set and specification, and test is responsible for validation and the ultimate advocate for the customer experience. Everyone is responsible for quality and performance, each bringing their perspective to the work. For any given feature, each of dev, test, and pm work as a team of peers (both literally and conceptually). This is a key “balance of power” in terms of how we work and makes sure that we take a balanced approach to developing Windows 7. Organizationally, we are structured such that devs work for devs, sdets work for sdets, and pm works for pm. That is we are organized by these “engineering functions”. This allows for two optimizations—the focus on expertise in both domain and discipline and also the ability to make sure we are not building the product in silos, but focused on the product as a whole.
We talk about these three disciplines together because we create feature teams with n developers, n testers, and 1/2n program managers. This ratio is pretty constant across the team. On average a feature team is about 40 developers across the Windows 7 project.
We also have core members of our engineering team that work across the entire product:
Some have said that the Windows team is just too big and that it has reached a size that causes engineering problems. At the same time, I might point out that just looking at the comments there is a pretty significant demand for a broad set of features and changes to Windows. It takes a set of people to build Windows and it is a big project. The way that I look at this is that our job is to have the Windows team be the right size—that sounds cliché but I mean by that is that the team is neither too large nor too small, but is effectively managed so that the work of the team reflects the size of the team and you see the project as having the benefits we articulate. I’m reminded of a scene from Amadeus where the Emperor suggests that the Marriage of Figaro contains “too many notes” to which Mozart proclaims “there are just as many notes, Majesty, as are required, neither more nor less.” Upon the Emperor suggesting that Mozart remove a few notes, Mozart simply asks “which few did you have in mind?” Of course the people on the team represent the way we get feature requests implemented and develop end to end scenarios, so the challenge is to have the right team and the right structure to maximize the ability to get those done—neither too many nor too few.
I promised myself no post would be longer than 4 pages and I am getting close. The comments are great and are helping us to shape future posts. I hope this post starts to develop some additional shared context.
Many folks have commented and written email about the topic of performance of Windows. The dialog has been wide ranging—folks consistently want performance to improve (of course). As with many topics we will discuss, performance, as absolute and measurable as it might seem, also has a lot of subtlety. There are many elements and many tradeoffs involved in achieving performance that meets everyone’s expectations. We know that even meeting expectations, folks will want even more out of their Windows PCs (and that’s expected). We’ve re-dedicated ourselves to work in this area in Windows 7 (and IE 8). This is a major initiative across each of our feature teams as well as the primary mission of one of our feature teams (Fundamentals). For this post, I just wanted to frame the discussion as we dig into the topic of performance in subsequent posts. Folks might find this post on IE8 performance relevant along with the beta 2 release of IE 8.
Performance is made up of many different elements. We could be talking about response time to a specific request. It might mean how much RAM is “typical” or what CPU customers need. We could be talking about the clock time to launch a program. It could mean boot or standby/resume. It could mean watching CPU activity or disk I/O activity (or lack disk activity). It could mean battery life. It might even mean something as mundane as typical disk footprint after installation. All of these are measures of performance. All of these are systematically tracked during the course of development. We track performance by running a known set of scenarios (there are thousands of these) and developers can run specific scenarios based on exercising more depth or breadth. The following represent some (this is just a partial list) of the metrics we are tracking and while developing Windows 7:
We have criteria that we apply at the end of our milestones and before we go to beta and we won’t ship without broadly meeting these criteria. Sometimes these criteria are micro-benchmarks (page faults, processor utilization, working set, gamer frame rates) and other times they are more scenario based and measure time to complete a task (clock time, mouse clicks). We do these measurements on a variety of hardware platforms (32-bit or 64-bit; 1, 2, 4GB of RAM; 5400 to 7200 RPM or solid-state disks; a variety of processors, etc.) Because of the inherent tradeoffs in some architectural approaches, we often introduce conditional code that depends on the type of hardware on which Windows is running.
On the one hand, performance should be straight forward—use less, do less, have less. As long as you have less of everything performance should improve. At the extreme that is certainly the case. But as we have seen from the comments, one person’s must-have is another person’s must-not-have. We see this a lot with what some on have called “eye candy”—we get many requests to make the base user interface “more fun” with animations and graphics (“like those found on competing products”) while at the same time some say “get rid of graphics and go back to Windows 2000”. Windows is enormously flexible and provides many ways to tune the experience. We heard lots on this forum about providing specific versions of Windows customized for different audiences, while we also heard quite a bit about the need to reduce the number of versions of Windows. However, there are limits to what we can provide and at the same time provide a reliable “platform” that customers and developers can count on and is robust and manageable for a broad set of customers. But of course within a known context (within your home or within a business running a known set of software) it will always be possible to take advantage of the customization and management tools Windows has to offer to tune the experience. The ability to have choice and control what goes on in your PC is of paramount importance to us and you will see us continue to focus on these attributes with Windows 7.
By far the biggest challenge in delivering a great PC experience relative to performance is that customers keep using their PCs to do more and more things and rightfully expect to do these things on the PC they own by just adding more and more software. While it is definitely the case that Windows itself adds functionality, we work hard to pick features that we believe benefit the broadest set of customers. At the same time, a big part of Windows 7 will be to continue to support choice and control over what takes place in Windows with respect to the software that is provided, what the default handlers are for file types and protocols, and providing a platform that makes it easy for end-users to personalize their computing experience.
Finally, it is worth considering real world versus idealized settings. In order to develop Windows we run our benchmarks in a lab setting that allows us to track specifically the code we add and the impact that has. We also work closely with the PC Manufacturers and assist them in benchmarking their systems as they leave the factory. And for true real-world performance, the Microsoft Customer Experience Improvement Program provides us (anonymous, private, opt-in) data on how machines are really doing. We will refer to this data quite a bit over the next months as it forms a basis for us to talk about how things are really working, rather than using anecdotes or less reliable forms of information.
In our next post we will look at startup and boot performance, and given the interest we will certainly have more to say about the topic of performance.
As the community participates in the E7 blog, we want to offer some guidelines on how we are going handle comments in general. Our primary goal is for this to be a place for open discussion about Windows Engineering, so we don’t want to have lots of overhead and process.
We love comments. We know everyone on the Windows team will be watching for comments and is looking forward to the dialog. We will work to make sure that Microsoft employees represents themselves as such, especially if they work on Windows.
Things we want to see in comments:
Things that will get comments edited/deleted:
We hope these rules will keep the discussion lively and on topic.
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.