Sinofsky posts on the Windows 7 team

While last week's initial posting on the Engineering Windows 7 blog was as content-free as everything else Microsoft has "communicated" about its next OS, today's second post, about the Windows 7, is a bit more interesting:

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.

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.

There's actually quite a bit more, so check out the original post. And for the love of God, let them know what you think, and what you'd like see in Windows 7. Are they really listening? Yeah, I think they are.

"Are they really listening? Yeah, I think they are."
Only as much as any company that will make billions in profit per quarter regardless of how good or bad the product is
MS -- or more precisely its customers -- are a victim of its success

FTLO. (Feature Team List Optimization) Note that when a team name is X and Y, that X is uniformly higher in the alphabet than Y, thus putting the team higher in the list than Y and X would have. There must be meaning in there somewhere.
--John (who was near the top of the lists throughout school (and Army basic training), which is both good and bad)

drylight
Paul really did cut out a lot of detail that Steven Sinofsky has in the original blog post.
What you may have missed is that he pulled key paragraphs from the original post and didn't just quote the, say, first 5 paragraphs verbatim and leave it ending in the middle.
So, I'd call this the "Readers Digest" version. To get all the meat, go to the original. There's even more good content there.

Sinofsky has definitely instilled some additional confidence with this blog. He's even responding to some of the respondent's when they chime in with good input. This makes me more optimistic about Seven than before.
Cesjr - I could easily argue that to some extent on the victims of success, you are somewhat right. However, I could easily argue that Apple is also a victim of their success, and the hubris shows with Mobile Me and the iPhone 3G's problems. Clearly the need for beta testing and communication is needed. Sinofsky is clearing be cautious but opening things up.
Lets not condemn Windows Seven, since we've not seen anything definitive yet. At this point, its speculation until we see a beta or CTP.

I like what he has written. Sure, he doesn't say what will be Windows 7, but he does kind of install confident in the sense that it should be solid, and they'll know who is accountable etc. Hopefully this way things will not get massively delayed. It's all bite-size, manageable chucks, probably with nothing "massive" going on.. I think it's great. I personally love Windows Vista, but perception is everything, and it's this kind of approach that will go some way to fixing the damage of Vista, for Windows 7.

Hmm....What, praytell, is the "VM" portion of "Kernel & VM" exactly?
Is this just another pseudonym for backwards compatibility or is this related to the proposed VHD support....or the latter for the former? (One can only speculate where this is going)

Waethorn
Most likely it has nothing to do with the kind of VM that's used by HyperV or VMWare.
Each process in the OS has its own virtual machine (it's confusing that they have the same name but that's life in software) and so the creation and configuration of each process is handled by a virtual machine manager.

Ambition is nothing without foucs:
I think the reason that windows will ALWAYS be evolutionary as opposed to revolutionary lies in the fact that no one has actually sat down, and spent time gathering information and DEFINING what an OS experince should be. To this date, I still feel like MS develops these things in isolation. Sure they probably bring in focus groups and do user testing, but in reality, we are not privy to the reasoning behind the changes they are implementing..until they are actually implemented. The list of things they seem to be focusing on sound like logical next steps for what is already in place and I have a feeling that win7 at it's core will behave like all would expect it to behave.
I get excited for new OSs because poking around in a new os is just as important to me as actually using it for functional purposes. The only way that MS is going to get the average person excited will be to completely re-tool the way we think about windows as a network integrated OS.
From where I sit, Surface is the most enticing technology they have demoed in the last decade and what sucks is that it's relegated to a few kiosks.
Personally, I think MS should be focusing on developing the platform for internet based MSI application installtion. This way, Win7/Mesh enabled apps will install in the cloud and the desktop. This would open up a world of application portability and I think solidify windows as the winner in the cloud wars.

"If you look at the variety of system and app virtualization there's a lot of what you're talking about."
It seems like there is still a lot of room to bring the kind of quality hardware-supported virtualization like Hyper-V down to the app level though.
The closest thing I see that compares to this is SoftGrid, but it's not available directly on the desktop without a big back-end server infrastructure. I've never honestly tried it either, but it seems like it's an entirely software emulation driven option which doesn't expose hardware (real or virtualized) natively to an app.
There's a few ways to conceptualize this, but this one seems the easiest:
If you look at Hyper-V right now, you can see that child partitions exist that can contain entire OS environments. Fine. That works for legacy/cross-platform support. It's still clunky IMO, but it works. You have this complete little computer-within-a-computer there. Yawn! Now consider that you have this thing called the VMBUS happening there. What happens if you could stream API's from the host OS into those child partitions (let's just call it an "OS-BUS" for simplicity here)? Now all of a sudden you have these completely virtualized environments for applications, each with app-level access to hardware (they need to virtualize ALL hardware in Hyper-V for this to work obviously, or at least the hardware that each app requires, not just storage and IO like Hyper-V does now), and so each app runs in a hardware-level virtual "thin-OS" environment, sandboxed from the host OS, and segregated from other applications running in their own child partitions.
If you could create a virtualized environment that segregates processes (applications) each on it's own thin OS layer which resembles a complete OS with full-featured hardware to the apps in each child partition, the overall host OS just becomes a management system to provide those thin OS environments, while pushing Hypervisor control down-level. Why bother, you ask? Consider the security and stability benefits.
Now if you add to that a plug-in architecture for native legacy OS API's to the "OS-BUS" and you have this desktop-capable application virtualization system that destroys SoftGrid, and WINE, while providing hardware-level virtualization and thus, native performance.
http://en.wikipedia.org/wiki/Image:Viridian_Architecture.svg
I couldn't expect current x86 VT hardware to accomodate the level of hardware virtualization needed for that many child partitions running concurrently, but I don't think it's that far off.

@mike:
I'll (finally!) get a chance to play with Hyper-V. Decided to order a new server the other day for the store. Pretty light server - Xeon 3300 series quad core, 4GB of RAM, 3x 500GB SATA hard drives, Antec Titan 650, Intel S3200SH series motherboard....pretty cheap system. I don't need anything high end really, for what I do in my store. I've been working off of 4 lower end servers prior to this. Down the road I may consider something better, but OEM software deployments don't take much.
So I'll probably be putting Server 2008 with Hyper-V on it as a "management server" of sorts (I have the hardware connected to a KVM, so running the VM's in the GUI install will just be easier, and I don't need management software for 2 systems). It'll run SBS 03 R2 as a production VM, alongside a secondary storage server VM for deployment software (mainly the OPK and WDS for deploying software on new machines). Each VM will get it's own dedicated HDD, as will Server 08. I don't have a need for a huge server, but that one will have dual-GbE so I can devote each VM to a separate NIC for extra performance.
Eventually when SBS 08 comes out (and I get it in my Action Pack), I'll upgrade to that, and probably only run it exclusively.

BTW: I've seen SoftGrid, but they need to provide that kind of virtualization directly on the desktop. If they could do that, and do it correctly, it would eliminate legacy compatibility issues altogether.