Engineering Windows 7

Welcome to our blog dedicated to the engineering of Microsoft Windows 7

The Windows 7 Team

The Windows 7 Team

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):

  • Applets and Gadgets
  • Assistance and Support Technologies
  • Core User Experience
  • Customer Engineering and Telemetry
  • Deployment and Component Platform
  • Desktop Graphics
  • Devices and Media
  • Devices and Storage
  • Documents and Printing
  • Engineering System and Tools
  • File System
  • Find and Organize
  • Fundamentals
  • Internet Explorer (including IE 8 down-level)
  • International
  • Kernel & VM
  • Media Center
  • Networking - Core
  • Networking - Enterprise
  • Networking - Wireless
  • Security
  • User Interface Platform
  • Windows App Platform

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:

  • Content Development – the writers and editors that create the online assistance, web site, SDK documents, and deployment documents.
  • Product Planning – responsible for the customer research and learning that informs the selection of features. Product Planning also coordinates the work we do with partners across the ecosystem in terms of partnering through the design and development of the release.
  • Product Design – develops the overall interaction model, graphical language, and design language for Windows 7
  • Research and Usability – creates field and lab studies that show how existing products and proposed feature perform with customers

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.


Leave a Comment
  • Please add 8 and 5 and type the answer here:
  • Post
  • Steven,

    Thanks for the informative post and Mozart was correct.  Glenn Gould says he didn't have enough notes, so it is all what you are looking for.

  • give use more informations 4 pages are not enought ...

    Thanks for your work Steven

  • Now we are starting to see the complexity of Windows Development, all the Departments involved in the project and the complexity of the develop of a project like this, this maybe make understand some people how hard is to make a software that is both efficient and functional. I work as a Developer in Venezuela and know how hard is to please every petition and how hard is to make EVERYTHING work perfectly so for me this is a very good start for a new concept in make good software.

  • Hi Steven,

    Great detail on the post.  I hope the recent news regarding 2008 is not reflective of a trend in the coming windows releases.

    I recently installed the latest Visual Studio 2008 SP1 and I have to say, the new XAML forms designer is very impressive.  I hope that your team gets to utilize these new tools to develop the new user experience.  There has been a huge push in the user experience and the number of people involved in it is insane.  I hope this talent and hard work is leveraged in this new release or future releases.  

    The new Entity Framework, WPF, and WCF are all technologies that will help Microsoft deliver the next "awesome thing".

    As Carly Fiorina once said ~"we have all of the resources we need, now we just have to execute on the vision".

  • This blog is great, Steven. Thanks for the openness and receptiveness to your users. I think we all hit these blogs and complain because we're also passionate about Windows, and even the most critical of us want to see Windows rock everyone's world.

    One thing I would like to know is what plans Microsoft has for netbooks. Is Microsoft's strategy to wait for netbook hardware to beef up and then shoehorn Vista onto them? Or is there a more focused solution in the works?

    My coworker was showing me his new Acer Aspire, which runs Linux, and I must say I was really, really impressed. It does 95% of what people need at 1/10th the footprint. I'd love to see Microsoft match this.

  • Very enlightening post on just how complex the Teams really are. I too look forward to more posts and hopefully some snippets or two on the new features for Windows 7.

    There really is a huge anticipation for Windows 7 so hopefully it will deliver on not only your goals but the millions of Windows users around the world.

  • A bit scary to see IE is parts of the OS project. Many non-os components are probably "hidden" in other teams as well. When can we expect to see Office here? :-)

    If you made everything non-osish independent, with release cycles not necessarily matching the OS (delivered via Windows Update when done), maybe it wouldn't take 5 years to get the "OS" done (and a positive side effect for us lean-and-meaners, we would off course not install those updates:-)

  • Wow, what a nice way to describe how much ranting was done over the initial post (and hopefully prevent more in the future).  I can't wait till we're actually called for ideas and suggestions.

    I do have to say, I'm very impressed at microsoft's willingness for open and non formal communictation as a part of their development life cycle.  It definitly seemed to be missing from previous released.  

    Windows can be a wild beast, and I can't wait to tame the next release.

  • So, if my math are correct, there are 1000 developper on Windows 7. Quite a bit of people to manage. Well, I'm looking forward to your posts, I want to know why, among all the suggestion put forward, this one in particuliar isn't really feasible and the other is actually a great idea. I sure hope we'll have some details about what you may or may not plan to do in the next Windows.

    64 Bits only FTW!

  • Man, I do not envy those pm's. I hated Project Management when I was taking it as classes!

    I also like the idea of teams at movies, haha. It's nice to hear about the comraderie that can exist there.

  • wonderful! please post more details about it.

  • Not everyone is a geek and not everyone wants to read a long blog post. break up these blog posts under different category.

  • To the core DNS, Wins, IIS, AD, COM, Registry, teams, it would be great if it was written in managed code (LINQ, or Entity Framwork and Web Services) or even refactored native code (or even C++/CLI) so we didn't have to call legacy stuff that with old programming quarks via WMI (*shiver).

    Looking forward to the deep integration with powershell.

    Thanks again!

  • As anyone who reads Steven's internal blogs knows very well, if it is 4 pages long it must be real! In fact 4 pages seems short! And what marketting person would allow a 4 page posting?! :-)

  • Thanks for the great post Steven!  Personally I like long posts because some things just can't be condensed into soundbytes.  I know whoever is tasked with reading the comments will have a lot of posts to read through so I will be brief.  The three most important things the Win7 must provide are speed, stability, and an entirely new GUI.  The GUI is primarily where my interest lies at this point and it should blow consumers away.  While Aero is nice, it still looks like nothing more than a glossy refresh of the traditional Windows look as it has been since '95.  Win7 needs to bring us visually into the future.  I look forward to seeing what's in store for the GUI.


Page 1 of 11 (165 items) 12345»