It is actually pretty hard to get engineers to show a lot of exuberance, unless perhaps for the finals of the World Cup championships for football (soccer) or cricket. Microsoft engineers are no different, except for maybe one other event.

Each year, in early October, dozens of busses bring thousands of Microsoft employees from our Redmond, Washington campus to Safeco field, where the Seattle Mariners play baseball, for the annual company meeting. Something shy of 20 thousand employees usually attend in person with tens of thousands more tuning in online.

The last speaker is always Steve Ballmer. He always bursts on stage to thunderous cheers and loud, rocking music, such as “Eye of the Tiger,” from the “Rocky” movies. Steve then storms around the stage pumping up the crowd even more before he dashes down the steps and takes a lap around the infield. As he moves along through the crowd he hands out victorious high fives and receives many hearty pats on the back. At points along his path he pauses to pump up the attendees in the stadium seats before finally running back up onto the huge stage. He usually takes a moment to catch his breath, and then lead us through several rounds of my favorite chorus, “I LOVE THIS COMPANY.” The videos are easy to find, just try the video search at www.live.com and enter “Steve Ballmer company meeting.”

It’s true; Microsoft is a really cool company and, as the rest of this book will show, the best company in the world at which to be a software tester. Our rich history, great products and geeky traditions, like the company meeting and a pumped up CEO, help make Microsoft a great place to be an engineer.

For the first 24 years of Microsoft’s existence, the company vision was “A PC on every desk and in every home.” In many ways, Microsoft has succeeded in achieving that mission. But, with the rapid growth of the Internet, the need to deliver devices such as the Xbox, and a shifting focus to services, the company vision had to be updated. From 1999 to 2002, we used “Empowering people through great software—any time, any place, and on any device.” It was certainly a bigger and bolder vision than just focusing on PCs, but it was still not big enough. In 2002, we released a new mission statement, “To enable people and businesses throughout the world to realize their full potential.” Figure 1-1 shows the 2008 Microsoft corporate logo, which reflects this vision.

Figure 1-1. Corporate logo in 2008, updated to reflect the company vision.

During the company meeting in September of 2008, our CEO, Steve Ballmer, announced the new company mission statement, “Create experiences that combine the magic of software with the power of Internet services across a world of devices.” Projected alongside on the screen were images of PCs, servers, rich browser applications, and devices from cell phones to gaming consoles and others in between. The mission really is to bring software plus services to every powerful Internet connected device. The mission statement is in addition to the vision we released in 2002, and so we now have a vision and a mission statement. Interestingly, during the launch of the new mission statement, Steve paused for a moment to answer a question I found myself asking. What about the old vision of your potential is our passion? Steve commented that the original goal of “a PC on every desk and in every home,” had served for many years as both a vision and a mission statement for the company. He went on to say that we may never again have a single clear statement like that one to guide the company, but that is a reflection of our success and broad impact on the world. While I like the vision that focuses on helping others realize their potential, as an engineer I like the concreteness of software, the Internet, and a world of devices. As a tester this scares me because now my test matrix has once again been expanded.

Supporting the mission, we have six company values: Integrity and Honesty, Open and Respectful, Big Challenges, Passion, Accountable, and Self-Critical. Out of this list the one value that engineers most often reference is Big Challenges. This value is the one engineers use when they talk about the next big thing and why we need to do it now. Big Challenges also includes taking smart risks, being persistent but not inflexible, and being courageous but not reckless.

Upholding our mission and taking on big challenges are common bonds that drive the engineers at Microsoft. These values are what drive testers at Microsoft to keep working hard to find that next bug, and the next one after that, so that our customers can have great products.

When asked why he joined Microsoft to replace the retiring Jeff Raikes as president of the Business Division, Stephen Elop covered several points that contributed to his decision, but focused on a single word that clearly resonated with the audience: impact. “Joining the Microsoft team represents an opportunity to positively impact the life and work of millions of people around the world. There is nothing more gratifying than having someone come up to you in an airport and saying ‘Look at what I have been able to do with your software’ "

Changing the world through software requires great products and the organizations to deliver those products. Microsoft is notorious for reorganizing our engineering workforce. Although this notoriety is well founded, for several years at the top level we have had the following three divisions of product engineering:

Tip

Internally, the Business Division is known as the MBD, which stands for Microsoft Business Division; this is because BD is not a TLA (three-letter acronym) and the use of TLAs to refer to every single product and team is hard-wired into the culture.

Essentially, all software development is managed by these three divisions. Each division is run by a president that reports to our CEO Steve Ballmer, who also has many other direct reports. By the time this book ships, Bill Gates will have retired from full-time work at Microsoft, but he will probably show up in organization charts for many years to come. Figure 1-2 shows a simplified organization chart for Microsoft.

Figure 1-2. How the three product engineering divisions fit into the organization.

Each division generates billions of dollars in profit on $10 billion to $20 billion in revenue, making each division bigger than many Fortune 500 companies. In each division there are dozens of products. Some of the products generate a lot of revenue and profit, others are investments and don’t turn a profit for many years.

What holds a division together is its focus on its market segment and customers: E&D is about entertainment, MBD is about software for businesses, and PSD builds the platforms on which our partners and other teams at Microsoft build to provide solutions for their companies or customers.

Our chief software architect, Ray Ozzie, reports directly to Steve Ballmer, as do many other senior leaders, such as Kevin Turner, Chief Operating Officer (COO), and Brad Smith, senior VP of our Legal and Corporate Affairs team (LCA). There are some software engineers in all parts of the company, even human resources, but the vast majority of engineers and testers work in these three divisions.

The fact that Microsoft is a big company is no surprise to anyone: In January 2008, Microsoft employed more than 90,000 people worldwide. The impact this size has on how things are done at Microsoft is important to understand.

For Microsoft, big is really about breadth—the breadth of the product portfolio that ships to market every year, the breadth of the markets Microsoft sells and competes in, and the breadth of the engineering challenges the company takes on to meet all of these demands.

For example, the breadth of the software product offerings from Microsoft is vast. In fiscal year 2007 (July 1 through June 30), Microsoft shipped more than 100 major products such as the Microsoft Office system, the Windows operating system, games and game consoles, home entertainment products, business solutions such as customer relationship management (CRM) software, mobile embedded devices, consumer Web services such as Live Mail and Search, and small business Web services. Microsoft is beginning to invest in services in the business-to-business (B2B) space and is continuing to expand in other emerging software markets. Microsoft continues to invest in robotics, Internet Protocol–based Television (IPTV), and in automotive PCs.

Equally stunning are the number of markets Microsoft ships products to. When Microsoft releases a new software product or service, we typically simultaneously ship, or “sim-ship,” it worldwide. This requires almost every product to have content translated into more than 80 languages and dialects. Table 1-1 shows the breadth of some products in the Microsoft portfolio.

The size of the company and the diversity of the portfolio explain why there is no one way to build and ship products at Microsoft. At its very heart, Microsoft is a software company powered by the innovations of its employees. Even across diverse products and processes, product groups share many of the same best practices and tools used for testing software. Part I of this book focuses on the people side of Microsoft: how we organize teams, and how teams approach challenges in testing the breadth of software Microsoft offers. Part II through 4 explain and demonstrate how our best practices and tools work.

We have two major organizational models for the engineering workforce. As a business goes from incubation to maturity, it may evolve from one model to another. When Office first started, it wasn’t even Office. It was Word and Excel, and then PowerPoint and Access. For several releases each product was developed and shipped independently. This model for greater independence to ship is often referred to as the PUM (Product Unit Manager) model, and is the most common across Microsoft.

With the PUM model a team manages all the engineering assets they need (or at least can get) in one single organization. They typically do not have to take dependencies on other teams unless it’s for some technology another team is close to shipping. The PUM model is ideal for rapid shipping and adjusting to competitors, but it does not allow for the centralization of common functions, such as build or test automation tools. With this approach, duplication of effort is higher, as is communications overhead. Almost every product, no matter how mature, still has some of these smaller teams within it. Both Microsoft Office and Windows still use the PUM model for incubation features while trying to ship major versions.

Figure 1-3. The common PUM model for engineering teams.

The Shared Team Model

As products and product categories mature, teams usually get much bigger, and centralization to improve efficiencies and reduce costs starts to happen naturally. This model has many names, but the shared team approach is probably the best. With the shared team approach, common features and tasks are placed into a central shared team, and the other product teams must take dependencies on this team or they won’t be able to ship successfully with the right feature set.

Microsoft Office is a great example. From the day someone had the brilliant idea that we should bundle our productivity applications and sell them as a suite, the Office team has been headed down the path of a shared team. In fact, Office calls this the Office Shared Services team (OSS).

Figure 1-4. Typical Office organizational structure.

Within the Office organization there are product teams (Word, Excel, and Sharepoint) that focus on a particular applications and the user base that relies heavily on them, and then there are shared teams (User Interface, Build, and Document Lifecycle) that focus on shared technologies and scenarios. The product teams tend to focus on their specific customer base (Excel cares about what’s best for the spreadsheet user), but they do that in the context of shared initiatives (what’s the best way to convey our user interface consistently such that someone learning Office only needs to learn one approach). By doing this they enable innovation in each product category while still maintaining consistency. Those goals can be at odds with each other, but having teams that represent each constituency working together results in a comprehensive vision for the design, development, and testing of the overall Office product release.

The same thing happens in Microsoft engineering, and test, specifically. Each product team has a test team focused on innovative ways to verify the functionality of its products, but there are great gains to be had by innovating on a consistent set of test tools and approaches whenever possible. Because of this, Office is able to create innovative approaches to specific products, such as Feature Crews (covered in Chapter 3), OASYS (Office Automation System) for automated testing, and Big Button for pre-checking tests.

The shared model not only produces efficiencies it forces creative contention. A shared team may have unique insights for common look and feel but the needs of a particular user segment might not be met by the initial designs. Shared infrastructure that isn’t of high enough quality will slow down the other teams and if quality isn’t improved they will work around the share team.

There are many variations between the full PUM model and a full Shared Team model. In fact there are probably no instances within Microsoft where any two teams have the exact same org structure and approach to engineering their products. Many people have used the metaphor that from the outside Microsoft looks like a battleship, but when you look at it from inside we are more like a bunch of speed boats rushing about to get to a common end point, but all in our own way. A friend of mine came up with a much better analogy for Microsoft product engineering teams.

Shipping a Software Product Is Like Producing a Play

When I started at Microsoft, I struggled to rationalize all the different processes, practices and engineering roles, which led me to think about how things get done around here. On one hand, we need creativity and innovation. On another, we are a big company. Somehow, it would not reconcile; what makes a large company successful rarely drives innovation at the root level. The analogy that helped me understand the environment was with a performing arts organization. As with any theatre company, we have directors, producers, actors (engineers, naturally!), A-list and B-list stars, stage producers, and other enabling folks. The idea is that while everything in performing arts is about creativity, make no mistake, a theatre production has to sell tickets, that is, find its customer. Trendsetting and having foresight about what will be popular is just as important in performing arts as it is in software development, especially in the current experience-driven world.

Marketing, sales, legal positioning of edgy subjects, and such play their role as well. The way I connected it with Microsoft was that executives and finance are producers, GMs are directors, and engineers are actors. Everyone else has a role that’s parallel to a role in theatre production. Innovation is a driver of the product similar to creativity in theatre. Trendsetting is the same as introducing a breakthrough product. Once I built that connection, I felt like I did when I stood in the wings of my beloved Kirov Ballet, watching my good friend and neighbor dance; I felt I had arrived and made sense of this weird, fascinating, oh-so-treasured Microsoft Wonderland. The Alice in me felt as though she had reached the bottom of the Rabbit Hole.

The key to the whole analogy is balancing the contradictions of a large software company that has to produce big profits with high margins and be dynamic and creative at the very same time. There is some inherent conflict between large production scale and creativity; balancing them successfully is a core of the success of Microsoft. No Google, or Apple, or Sun has quite yet mastered this challenge at scale. Only the likes of Cirque du Soleil and Microsoft have proven they can do it.

—Irada Sadykhova (Director, Engineering Learning & Organization Effectiveness – Engineering Excellence)

Microsoft isn’t just about big businesses. We start many small businesses in the process of looking for that next big thing.

I once heard Bill Gates compare Microsoft product development to the movie industry. He made the analogy that every big movie studio places bets in different categories. One category is the blockbuster movie such as the latest remake of King Kong. Typically, these are very expensive movies to produce and come with a great deal of risk—they are either a box office bomb, such as the 2002 Eddie Murphy movie The Adventures of Pluto Nash, which is considered the biggest flop ever with a budget close to $100 million and box office receipts of only $4.4 million, or they are a breakthrough winner, like the reigning box office champ Titanic, which earned $1.8 billion worldwide, or Napoleon Dynamite, which turned a $400,000 investment into more than $46 million at the box office (not counting DVD and other sales). Another category includes the second or third installment of franchise movies such as Spiderman II and Spiderman III or any of the sequels in the Star Wars series. Big box office receipts are expected from these franchise movies.

All movies have a goal of being profitable, but risk is often mitigated by reducing the level of investment. Bill’s point was that there will always be unexpected hits and successful franchises, but the key to long-term success is to spread the risk across a large portfolio and to try to find that next big franchise movie. The predictable long-term profits from a franchise can then be used to fund other projects that might yield the next big movie series. Peter Jackson’s “Lord of the Rings” series and the Harry Potter movies, which have had multiple directors but are all based on the books by J. K. Rowling, are examples of big bets that paid off with multiple highly profitable releases. In fact, both of these franchises have more movies in the works. Peter Jackson is developing two movies based upon The Hobbit, and there are three more Harry Potter books yet to be made into movies.

The Microsoft product strategy strongly parallels that of the movie industry. Profits from big and successful businesses such as Microsoft Office, Windows, Visual Studio, Exchange, SQL Server, Hotmail, and MSN Messenger are invested in incubation projects that have the potential to be the next big businesses. In the software industry, incubations are common. The term incubation is usually applied to a small start-up software company that has yet to release a product but whose idea seems sound and whose target market looks to be worth going after. Start-up teams at Microsoft are typically managed by a General Manager (GM) for large efforts or by a Product Unit Manager (PUM) for smaller efforts. These teams are usually self-contained units that have most of the engineering resources they need in-house. Their destiny then lies in their own hands.

Microsoft invests in internal incubation projects such as our IPTV, Auto PC, and robotics projects as well as all the work done by Microsoft Research (http://research.microsoft.com). We also invest in projects that can help spur change in the software industry as a whole. In April 2007, with more than 10 partners we launched the Microsoft Software as a Service (SaaS) Incubation Center Program.

In Microsoft, there are many models for incubations. Established products often incubate features in the larger organization. For example, the Office 12 ribbon, a new feature that changed the Office user interface, and the Windows Vista shuffle feature were incubations. The code coverage tools that ship in the latest versions of Visual Studio were based on concepts developed first as internal tools projects in Microsoft Research and Windows.

Another approach we’ve used to incubate innovations is using an internal venture capital team. Any employee can submit an idea, and the venture capital team will examine the feasibility of the idea using a process much like an industry venture capital firm would use. Just like in industry, very few ideas get funding through this mechanism.

The Bill Gates ThinkWeek is another source of ideas that can become incubations. Microsoft employees can submit white papers detailing new ideas and innovations, and during ThinkWeek, which occurs approximately twice each year, Bill reads and comments on scores of papers. At the end of the week, Bill’s notes, once hand-written, are shared with the company. In 2005, the Wall Street Journal described ThinkWeeks in this way:

For the Fall 2008 ThinkWeek, 375 papers were submitted and Bill was able to comment on 125 of them. This program was established to encourage employees to submit innovative and forward-thinking ideas. Many of the more promising ideas receive funding for initial development. Bill also publishes his recommended reading list to the company. Recently, a white paper I wrote on how to improve our software services testing made Bill’s recommended reading list, and for me it was like receiving a stamp of approval on what until then was just theories.

Microsoft recently began using a process called Quests to innovate new ideas. The dictionary defines the verb quest as “to search and seek.” At Microsoft, a Quest is about mapping our long-term aspirations and goals. The Quest process brings together senior technical thought leaders from across Microsoft to create a 5- to 10-year vision for technology innovation. Through the Quest process, Microsoft’s top technologists work collaboratively across organizations and product groups and with the business leadership to architect technology advances that will offer the greatest potential to transform people’s lives at work and at home, and create new business opportunities for Microsoft, our customers, and our partners.

Quests do not raise simple problems with simple answers. Typically, a Quest takes many years to complete and likely requires new research, generates many prototypes, and discovers unique insight that often precedes the creation of a new market. A successful Quest must be customer-centered, visionary, directional, and rigorous. This last point is the part where our values of Integrity and Honesty and Open and Respectful intersect. Rigorous for Microsoft Quests means extensive peer review combined with oversight from the company’s Senior Leadership Team, which includes all three presidents, Steve Ballmer, and a few other executives.

Quests are not about producing another version of a product but are more about managing a portfolio of long-range technology problems that by design require us to work across groups to find and use synergies. The number and areas of focus for Quests continue to change every year as some Quests end and others merge. Currently, more than 50 Quests spanning the entire range of Microsoft businesses and all customer segments, from consumer and information worker to IT pros and developers, are in progress.

Because Microsoft is both a product and a platforms company, it has a vast array of partners who have their own software engineers working to innovate on top of what Microsoft has shipped. Vendors and partners who work with Microsoft make the engineering force of Microsoft well more than 100,000 software engineers worldwide. Compared with the full ecosystem made up of millions of software engineers around the world working on Apple, IBM, Sun, Oracle, and open source software such as Linux, the Microsoft engineering force is a small percentage. Still, it is perhaps the most powerful and influential engineering force in the market today.

Note

There are more than 35,000 software engineers working full time for Microsoft in more than 40 countries around the world. Each year Microsoft hires more than 5,000 new software engineers and more than 1,000 new software design engineers in Test.

Compared with most other companies, Microsoft is unique in both its engineering processes and its management of software engineers. Some might look at the company’s success in the software industry and point to these unique differences as key competitive advantages. Others point to some of our products and their major slips and wonder if these differences are a weakness.

So, what are the software engineering factors that make Microsoft unique and different from any other company in the world?

The Engineering Disciplines

When you break down the roles of the more than 80,000 employees worldwide that work directly for Microsoft, of the total employee base, you find that more than 35,000 are in sales, marketing, and IT. Product Engineering is the part of the company that develops and supports the software products, and as of early 2008, Microsoft employs nearly 35,000 engineers worldwide. The other 10,000 employees span a number of other disciplines ranging from business administration to legal. Although Microsoft continues to grow at a rapid rate, the balance of sales, marketing, and IT with Product Engineering has been a relative constant for many years.

Product engineers are the employees who actually work to create and ship the products—hardware, software, and services—that Microsoft sells to customers. Microsoft engineering roles break down into the following 10 product-engineering disciplines:

• Test. Software Development Engineers in Test (SDETs) are usually just called Test and sometimes Software Testing. SDETs are responsible for maintaining high testing and quality-assurance standards for all Microsoft products.

• Development. Software Development Engineers (SDEs) are often referred to as Software Development. SDEs write the code that drives Microsoft products and upgrades.

• Program Management (PM). PM is a rather unique role in Microsoft that combines elements of project management, product planning, and design into one discipline. The PM’s job is to define a new product’s technical aspects and oversee its hands-on development.

• Operations (Ops). Ops is part of Microsoft Information technology (IT). The Ops discipline manages and maintains Microsoft online services as well as internal corporate IT infrastructure, from networks to servers. Ops works closely with the product teams on service architecture to lower production costs and make our services more reliable.

• Usability and Design. Usability Experience and Design (UX) combines the roles we advertise as product design and usability. Design focuses on the visual and functional front-end user experience for Microsoft products. Usability also focuses on the end user experience but conducts new research to see how the user works with existing products and new prototypes, and then analyzes the results to help improve products during development.

• Content. Content is still called User Assistance and Education on our external sites. This discipline plans and delivers assistance—including UI text, Web articles, training, templates, columns, books, quizzes, and Help files—to help customers get the most from Microsoft products. The shift to the title Content emphasizes Microsoft’s need to focus on content that can be used across multiple delivery vehicles.

• Creative. Creative positions exist most often in the Games group. Engineers in this discipline develop and improve Microsoft’s cutting-edge games software for the PC and for the Xbox game console. The Creative discipline includes game designers as well as artists.

• Research. Research includes subroles for developers and testers. The difference between a research developer and a product developer is the emphasis upon research, publishing papers, and incubating new technologies as opposed to shipping a product on a schedule.

• Localization. International Project Engineering (IPE) used to be known as Localization. The localization component of the discipline focuses on translation of Microsoft software into multiple languages and adaptation of software for different cultures. The IPE discipline is also responsible for adapting Microsoft software for specific market needs.

• Engineering Management. Engineering Management is made up of the managers who run teams that include multiple engineering disciplines. They often go by titles such as Product Unit Manager, General Manager, or Group Manager.

Note

Hardware is considered a specialty area and includes disciplines such as Hardware Developer, Hardware Tester, and even Hardware Program Manager. These disciplines are similar to their cousins in the software and services spaces but are different enough to warrant their own career path and training support.

Product engineers are aligned by disciplines. The number of engineers in each discipline varies from more than 10,000 in the largest discipline down to hundreds in the smallest discipline. The three largest disciplines are Development (SDE), Program Management (PM), and Test (SDET). The fourth largest and rapidly growing discipline with the corporation’s shift to services is IT Operations (Ops).

Microsoft didn’t always have this separation of disciplines. In the early years, everyone’s title was “technician.” Specialization into roles started in 1979, and the use of different standard titles to identify career paths for engineers started in the early 1980s.

The triad is the name we use for the Test, Development, and Program Management disciplines, as shown in Figure 1-5. These are the three largest engineering disciplines in Microsoft, and significant numbers of engineers in each triad discipline are involved on a product team. With the shift in focus to software and services, IT Operations is growing quickly.

Figure 1-5. The Test, Dev, and PM triad.

Most of these engineering disciplines are common to any large software company. Each has its industry events such as the Software Testing Analysis and Review (STAR) conferences for Test or DEFCON (http://www.defcon.org) for security developers. Conferences are designed to develop skills and promote the overall profession.

Software testing is one of the larger disciplines both in Microsoft and in the whole software industry. In this book, we hope to share with you the stories of Microsoft testers to help illustrate points and to share what makes Microsoft testers both similar to and sometimes different from their industry counterparts.

Testers break the 128-KB RAM barrier

In 1985, money for equipment for testers was very tight. Excel for Mac could run on 128 KB, so that was the best test computer anyone had. As the team started working on the next version of Excel, the memory requirements grew to 512 KB. For quite a while, the testers didn’t get new equipment. Finally, though, when it became clear that the testers just couldn’t do our jobs, we were given memory upgrades.

—Carole Cancler, former Microsoft Tester

People often ask whether all of the products Microsoft creates are developed in Redmond, Washington. The short answer is, most are, but not all. Microsoft was a global company well before moving into its Redmond headquarters in February 1986. In fact, Microsoft’s first international office opened in Japan in 1979. In 1998, Microsoft was still very Redmond-centric with more than 90 percent of product development engineering happening on the main campus.

Today Microsoft has sizable and rapidly growing development centers all across the United States and around the world. The largest U.S. sites are in California, North Dakota, Massachusetts, New York, South Carolina, Texas, and Colorado. Internationally, the Microsoft development centers in China and India each employ more than 1,200 engineers. For the release of the new Windows Vista operating system, major components were developed in North America, Europe, and Asia. Future releases of the Windows operating system and Office system will have even larger international contributions.

As shown in Figure 1-6, by 2004 the Redmond workforce had dropped from 90 percent of the total engineering workforce to just 81 percent of the total workforce.

Figure 1-6. Top 12 Microsoft development centers in 2004.

This trend to spread the engineering workforce across multiple development centers continues to accelerate. In recent years, Microsoft has made large acquisitions and has chosen to keep the employees in their original locations. Rates for hiring employees in China and India have been ahead of Redmond for several years. As shown in Figure 1-7, by early 2008 Redmond-based engineers represented just 73 percent of the global product engineering workforce.

Figure 1-7. Top 12 Microsoft development centers in 2008.

The internationalization trend is by design, but the design, unlike that of many other multinational companies, is not about cheaper labor. The globalization of the Microsoft engineering workforce is about access to talent, access to markets, and taking advantage of new technologies. As graduation rates for computer science majors continue to fall in the United States and the wait for work visas to enter the United States continues to grow, Microsoft must go to where the talent is, and some great engineers just don’t want to move to Redmond, Washington, to work for Microsoft. Also, by hiring many engineers in a specific country, Microsoft can help open and stabilize the market there. For example, with so many Microsoft engineers now working in China in that country’s rapidly growing technology sector, the government of China now has a vested interest in reducing software piracy because it affects its own citizens and the work they do. In addition, the technology that Microsoft develops allows for greater collaboration among our global engineering workforce. Small teams are better able to be connected to the whole than they were even just a few years ago. Judging by the current rate of change, I expect Redmond to be the home of less than 50 percent of the total engineering workforce in the next decade.

Note

At the beginning of 2008, the Microsoft India Development Center (IDC) employed more than 2,400 engineers. Microsoft employs more than 1,400 engineers in the Shanghai and Beijing facilities.

Microsoft is the world’s biggest software company and the best place in the world to be a software test engineer. We build successful world class businesses that generate big revenue and big profits. The rich history of Microsoft, our broad vision to empower the people of the world and a core set of values that help guide the test engineers of Microsoft in shipping world class high quality software.

As businesses evolve, the engineering practices used by the large successful business groups have evolved from the PUM-based organization structure to the more scalable and efficient Shared Team organization structure. Microsoft invests in incubations both in established products and in brand-new product categories.

More than 35,000 product engineers work for Microsoft across 10 different engineering disciplines. Microsoft engineers develop hardware, desktop application, server, and service products. Product development at Microsoft is becoming more and more globalized. As of 2008, more than 28 percent of product development is happening outside of Redmond, Washington, and this trend of global development is expected to continue.