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 - Information on Terms of Use.
Notes on comments.
Welcome to our blog dedicated to the engineering of Microsoft Windows 7
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.
--Steven
I am curious about how new features get proposed and kicked around. How often does a developer put something in on their own time?
Hi Steven,
Loving the posts, great content. It's also finally good to see revealed the complexity of Windows, and that's something Microsoft should have done ages ago. Being in software development, I know just how complex a project can be, but most people would not and assume doing is as easy as saying so.
Thanks again, and keep up the good work! :-)
I'm very puzzled by the postings expressing surprise at the size of the team and the complexity of windows. I'd have thought, from the outside, that was a given. In fact, given how small the described numbers of engineers are the conclusion I would draw is 'this is why versions are so similar to each other and it can take several versions for mistakes to get fixed'.
In one of my earlier comments I proposed a formal split between kernel, session layer, and UI. That seems more urgent than ever based on what is described here.
And As for the comment by hardon, I agree entirely. If IE8 is regarded as 'part of the OS' then we are in trouble. Is this a legacy of the W2K days when the desktop was the explorer was IE? I really do think that you need to make the desktop a separate 'product' that can run on any kernel.
Imagine if 'vista basic' had consisted of the existing XP desktop running unaltered on a smaller, hardened, kernel. And 'vista gamer' could have been completely separate?
I do appreciate the effort to give us a peek into the development of Windows 7. I only wish this had been part of the Vista development process. Maybe we would not have such a disastrous user interface, among other things, in Vista.
Honestly, my opinion of this blog being set up now is to prepare for PDC and WinHEC so that you guys with have the proper place to have your say.
My suggestion would be to say how you guys are doing what you're doing, and to start debunking rumors. These two are the best I can think of short of actual "feature" related news.
One last request, I would love to see a pledge for better x64 support. I know you guys are working on getting multi-thread and core working, and some other neat stuff, but Microsoft needs to make a pledge, like they did for security back in 2003 (and that one paid off well) to moving to x64.
I might just be saying this because I'm a x64 fanboy, but its important to me. Vista has a great deal of support for it, but there are still areas in which MS falls short. I'm holding you guys to the standard of quality I'm supposed to expect from Microsoft here (or whatever the apologist language was for Vista on a certain Microsoft page).
Having many teams is great, but there needs to be strong, decisive management to guide all these teams. In Vista, each team seems to have made a product and at the end they were strapped together. Just have a look at http://arstechnica.com/articles/culture/microsoft-learn-from-apple-II.media/vista.png. Not all of those are core operating system components, but all are made by Microsoft and lack consistency.
hey, thanks for the great Blog- I can't wait to get my hands on Windows 7. I wonder if MS is planning add old features like Win FS :)
And lastly I hope windows 7 has a productive UI. Because in my last 17 years of computing experience I haven't seen much of an improvment in this area, every OS has a same generic UI but the situation has now changed, we have different class of users - developers, administrators, gamers, home users and so on, it would be great if the OS has UI optimizations for these different users. As a developer I'd have wanted UI to be more helpful to speed up my work.
Anyway, this is just my opinion. Waiting for the next blog...bye
This blog is a nice opportunity for some interaction between the developers of the next generation of Windows. While companies have (always?) had access to the dev teams, regular users have always had a more difficult time being heard. I'll take this opportunity to share my views on what I would like the upcoming OS to be. I guess it comes off as a bit of a rant, but hey, don't read it if you don't want to. ;)
What I want most out of Windows 7 is choice. I'll acknowledge now that what I want to see is not something that will necessarily be easy, but I think it's the best thing Microsoft, as an entity, could provide for it's customers. Traditionally, the features set has been presented to users as a full set, whether it was needed, wanted, or not.
I'd like to see a more granular approach to features and the user interface. If a user does not want to have things like free-cell, minesweeper, Windows Media Player, or even some major features like Gadgets, to be on their machine, they should be able to choose not to install them the first time the OS is loaded to the machine.
Every user's needs is different - a fact demonstrated by the wide range of requests and comments received in response to the first blog entry. If a user knows what features they need, or want, to be using, the power to disable them would be of great benefit in the performance front. A leaner, meaner operating system install that caters to the specific needs of the user means that the experience of using the operating system will be as close to ideal as is wanted.
I don't want to see Windows 7 as another pretty GUI. To me, an operating system is a tool; a gateway to using the applications installed on the computer in the most optimal way. It is the job of the operating system to cater to our wants and needs. A shiny GUI looks nice, but the novelty factor wears off - and goes even quicker if there is no substance behind the eye-candy.
As a home user, I'll surf the internet, listen to music, dabble with some 3D Modeling, and play games on my computer. I do not want to have to buy a new machine, or even upgrade beyond the barest necessities, to cater to those functions. For me to want Windows 7, the operating system needs to facilitate these activities BETTER than Windows XP currently does.
While Moore's law continues to commodify computing power, storage space, and memory density, I do not want to have to replace my computer, or upgrade my ram, to get the same experience I do with an older operating system from the point of view of performance. Around the year 2003, computing hit a wall that Microsoft as a commercial entity, needs to acknowledge; for the vast majority of users, computers are more than powerful enough for their needs. People will not always be able to afford a new computer to get access to that new and shiny operating system, and so the OS should not be designed and tweaked to get "just enough" performance out of the increasingly powerful hardware.
I guess that's all I really have to say for now. I've RSSed this blog, and am definitely looking forwards to seeing future entries about the development of the operating system, and the direction it's taking. Good luck with the OS, because you guys need to get this one right on the money in the first shot. The alternatives are gaining quality every day.
kfunk and franklarson, I agree that this blog is a good idea; however, there was lots of openess with Longhorn/Vista too. Some have argued too much.
I admire how Microsoft has integrated blogging, forums, and more recently its video channels (Channel9, etc) and so on into its culture. I don't think there's any other tech company that reaches out to its customers and the community as much. It's highly welcome and something as a developer and an enduser that I've benefited from a lot.
There are several things that I hope will be addressed in Windows Seven.
First, I'd like to see any percieved or actual advantages of Apple's OS-X operating system. I'd like to see a really good answer to some of Apple's products such as iLife, Garageband, and others to truely have parity.
Second, I'd like to see some performance improvements over both XP and Vista. In my opinion as a user, the least amount of memory used should be the rule. The OS speed needs to be faster, noticeably faster. The bootup and shutdown needs to be quicker. PC gaming needs an overhaul. The equalizer in WMP could use a revamp.
Third, I'd like to be able to have greater ability to remove applications in Seven. One of the big complaints of Vista was that you couldn't easily remove Internet Explorer or Windows Media Player. We used to be able to do that in previous versions. I hope that is restored in Seven.
Finally, I trust you guys to manage the size and scope of the Windows Team. I believe that part of the management is the least of your problems. The big issue is getting Seven to be the best product it can be.
Good luck and God bless.
I think that it is going to be great being able to follow along with the development of WIndows7 as closely as this. It reminds me of what Nintendo and Masahiro Sakurai did with Super Smash Bros. Brawl if anyone here knows what I am talking about. Thank you for doing this and I hope you listen some of the user comments.
When I read "One thing we do try to avoid is separating the 'plumbing' from the 'user interface,'" I was extremely surprised. I had thought that Model-View-Controller has long been accepted as the desired architectural pattern. Why did you knowingly decide to develop with this anti-pattern?
It seems to me MVC would be very desirable for an OS so that the functionality is not only exposed though the OS's UI but also through 3rd party applications. If "Find and Organize" didn't build the indexer but instead one team built a generic component and one team built the UI that was Find and Organize, the engine may be able to be used also for Help indexing, email indexing, picture indexing, etc.
I think this would go a long way to improve both the developer and user experiences. If you had a core UI team, one would hope the API would be good enough to avoid the nightmare brought up by PRab. Instead, since each team does it end-to-end, it appears that each continues to reinvent the wheel because the APIs available aren't designed or developed well enough.
I am not a Windows developer. I've been too discouraged by the amount of work required by the API. Looking at NeXT's API, now Cocoa and seen what Apple and their third party developers have been able to do with them, or at the modularity and robustness of Linux, I think, gives much empirical evidence for the advantages of these patterns.
Correct me if I'm wrong but it seems like Microsoft is taking the ostrich approach to API evolution, largely keeping in line with 1980s development practices. I am sorry to be so pessimistic but I would like some insight on this, as it seems to be crippling Windows. Mac OS X has grown leaps and bounds, showing architecture makes a huge difference. Apple takes architecture so seriously they are using an entire release for refacotring and maintenance. While I think that's a little unreasonable it does lie in stark contrast to Windows, which many people feel innovation has largely stagnated, which I think can be fairly easily linked to its weak, shallow and ancient API.
For developers and investors (and end users since they're directly impacted), I think a discussion on this kind of architectural reasoning is very necessary.
@brian6504@comcast.net
You raise a super good point. There is both an organizatinal aspect and an architectural aspect to the discussion.
In terms of architecture it is absolutely the case that you want to define the right boundaries and have separations that always make sense. The example used (indexer and user interface) actually provides a case study in the complexity of separating out the plumbing from the interface. In the case of indexing and result sets, it is one of those things that starts of very clean of course and then you quickly hit real world issues such as size of result sets. If you have thousands of music tracks or tens of thousands of photos/files it means you have to have an interface that handles cursors and result sets well. Then you have the real-world aspects of dealing with an extremely interactive desktop user interface rather than a web browser -- so the expectation is page down and scrolling are "instant" and we don't have the benefit of showing 10 results and clicking next and reloading.
That doesn't mean there is no separation, but it talks about the architectural challenges. You can in fact see the indexer API we have today and it is cleanly separated. http://msdn.microsoft.com/en-us/library/aa965362.aspx.
From an organizatinal perspective, having the plumbing and interface together means we are designing for an end-to-end scenario for customers and not designing the perfect plumbing and the perfect UI that might not meet in the middle. This is really a statement about the product design and thinking about both the architecture and the experience an end-user would have.
PS: This is really me :-)
@Brian -
I think Steven was referring to having the Windows *team* divided up along end-to-end scenario boundaries, not the architecture itself.
In fact, within the Find & Organize team we do have separation. We have smaller sub-teams including a couple focused pretty much solely on the indexer.
And if you look at our API documentation and all the documentation we have around how the system actually works, you'd see that we do in fact have *many* levels of architectural separation (in fact, some may even think too many!) between the indexer and the Search UI components.
I think there are very real advantages to organizing our feature teams as Steven described, though. For example, having both the indexer and the search UI in the same team can help create a more coherent and consistent story for our development platform. Very rarely is a third-party going to want to write JUST an indexer plug-in to return search results. They probably also want to enable custom verbs for their results, along with custom icons, previews, etc.
I believe having one point of leadership that is responsible for these end-to-end scenarios facilitates successful implentation of said scenarios, for both end-user AND developer customers.
Brandon
Great and interesting post. You should also explain the development cycle a little, where Windows 7 is at, and what kind of suggestions made now have a chance of being included in Windows 7.
It's something that interests me quite a bit. Also, a lot of people are making suggestions that can never make it into Windows 7, even if it's the best idea in the world, because RTM is getting close to just one year out.