How many developers does it take to build Windows 7?

happygeek 0 500 Views

That's the question I had not thought of asking, nor really given much thought to at all, until now. What prompted the question was the appearance of the Official Engineering Windows 7 blog.

The third posting proved to be a fascinating read, providing the kind of insight into the development of a software project as large as Windows that frankly is hard to get anywhere else. This is real horse's mouth stuff. Steven, writing on behalf of the Windows E7 team, says simply that none of the posts are ghost written by the PR department but instead he is "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."

Which is cool.

But not as cool as the detail revealed about that team which is developing Windows 7.

"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" Steven says, continuing "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."

How big is a feature team? It varies, but the average is 40 developers per team. Each of these work on parts of the platform which have familiar sounding names. "In general a feature team encompasses ownership of combination of architectural components and scenarios across Windows" we are told.

Some of the main feature teams for Windows 7 include:

  • 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

Which brings me nicely back to that original question, and the answer we now know is at least 25 x 40, or 1000 developers at the very least.

Dani AI

Generated

As highlighted, a public engineering blog gives a useful peek but not the whole picture. "Developer" can mean different things: feature-code authors, component owners, or anyone who actually ships and supports the product. Public lists of feature teams are a good starting point, but they show only a slice of the people needed to deliver a modern OS.

Here are common groups that are often left out of simple headcount arithmetic:

  • Test and QA: manual testers, automation engineers, lab operators
  • Build, release and configuration management engineers
  • Program managers, product planners and UX designers
  • Performance, reliability and telemetry engineers
  • Security, privacy and compliance specialists
  • Driver authors and OEM/IHV partners (hardware/firmware teams)
  • Localization, documentation and accessibility teams
  • Support, servicing and sustained-engineering teams (patching)
  • Infrastructure, DevOps and lab-ops staff
  • Third-party ISVs and ecosystem partners

A practical way to move from "a guess" to a defensible estimate is to build a simple model. Decide which categories you count as "developers" for your purpose. Use the visible feature-team roster as the core, then add rows for each of the groups above and mark internal vs external. Populate known FTE numbers where available, flag the rest as estimates, and document assumptions (phase: peak vs maintenance, who is external, what counts as an FTE). Tracking certification and compatibility effort separately is useful, since those phases often pull in large numbers of partners and test resources for short bursts.

Headcount alone misses the delivery complexity: coordination, certification, driver and OEM ecosystems, test labs, and post-release servicing are what actually make an OS release succeed. The blog gives a helpful lens; a fuller model shows why the true effort extends well beyond the visible feature teams.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview