How Microsoft Builds How Microsoft Builds Software*Software*

Presented by: Ron NormanPresented by: Ron NormanSociety for Software QualitySociety for Software Quality

June 23, 1998June 23, 1998Michael A. CusumanoMichael A. Cusumano

Professor of Strategy & Technology ManagementProfessor of Strategy & Technology ManagementSloan School of ManagementSloan School of Management

Massachusetts Institute of TechnologyMassachusetts Institute of Technology

Richard W. SelbyRichard W. SelbyAssociate Professor of Computer ScienceAssociate Professor of Computer Science

Department of Information & Computer ScienceDepartment of Information & Computer ScienceUniversity of California, IrvineUniversity of California, Irvine

* Adapted from “How Microsoft Builds Software”, * Adapted from “How Microsoft Builds Software”, Communications of Communications of the ACMthe ACM, June 1997, Vol. 40. No. 6, pp. 53-61. This article is based , June 1997, Vol. 40. No. 6, pp. 53-61. This article is based on the author’s book: on the author’s book: Microsoft Secrets: How the World’s Most Microsoft Secrets: How the World’s Most Powerful Software Company Creates Technology, Shapes Markets, Powerful Software Company Creates Technology, Shapes Markets, and Manages Peopleand Manages People, The Free Press/Simon & Schuster, New York, , The Free Press/Simon & Schuster, New York, 1995.1995.

The ChallengesThe Challenges Quality problemsQuality problems

Delayed deliveriesDelayed deliveries

Larger development teamsLarger development teams– Win 95 had over 200 programmers and testersWin 95 had over 200 programmers and testers

Software products with millions of lines of Software products with millions of lines of

source codesource code

– 11+ million lines of code in Win 9511+ million lines of code in Win 95

Development lasting one or more yearsDevelopment lasting one or more years

Product ComplexityProduct Complexity

Components are interdependentComponents are interdependent

Components are difficult to define in early Components are difficult to define in early

stages of the development cyclestages of the development cycle

Need to proceed with coordination, while Need to proceed with coordination, while

allowing flexibility to be creativeallowing flexibility to be creative

Need a mechanism to test the product with Need a mechanism to test the product with

customers and refine the designs during the customers and refine the designs during the

development processdevelopment process

The need for iterationsThe need for iterations

Users’ needs are difficult to Users’ needs are difficult to understandunderstand

Software/hardware changes rapidlySoftware/hardware changes rapidly It is difficult to design a software It is difficult to design a software

system system completelycompletely in advance in advance Similar to the spiral model and Similar to the spiral model and

other iterative enhancement other iterative enhancement development processesdevelopment processes

Scaling up a flexible, Scaling up a flexible, entrepreneurial companyentrepreneurial company

Small team style (3-8 Small team style (3-8

developers)developers)

Many parallel teamsMany parallel teams

Freedom to evolve designsFreedom to evolve designs

Synchronize frequentlySynchronize frequently

Synch-and-Stabilize Synch-and-Stabilize ApproachApproach

Continually synchronize parallel teamsContinually synchronize parallel teams Periodically stabilize the product in Periodically stabilize the product in

increments versus once at the endincrements versus once at the end Also known as:Also known as:

– milestone processmilestone process– daily build processdaily build process– nightly build processnightly build process– zero-defect processzero-defect process

Overview of Overview of Synch-and-Stabilize Synch-and-Stabilize

DevelopmentDevelopment

Planning

Development

Stabilization

Planning PhasePlanning Phase Vision Statement - Product ManagersVision Statement - Product Managers Define goals for the new productDefine goals for the new product Priority-order user activities that need to be Priority-order user activities that need to be

supported by product featuressupported by product features Deliverables:Deliverables:

– Specification documentSpecification document– Schedule and “feature” team formationSchedule and “feature” team formation

1 program manager1 program manager 3-8 developers3-8 developers 3-8 testers (1:1 ratio with developers)3-8 testers (1:1 ratio with developers)

Planning

Development PhaseDevelopment Phase

Feature development in 3-4 subprojects Feature development in 3-4 subprojects (lasting 2-4 months each) using (lasting 2-4 months each) using functional specifications that outline functional specifications that outline product features in enough depth to product features in enough depth to organize schedules and allocate stafforganize schedules and allocate staff

Subprojects -- design, code, debugSubprojects -- design, code, debug– starting with most critical features and starting with most critical features and

shared componentsshared components– feature set may change by 30% or morefeature set may change by 30% or more

Development

Subproject DevelopmentSubproject Development

Feature teams go through the complete Feature teams go through the complete cycle of development, feature cycle of development, feature integration, testing and fixing problemsintegration, testing and fixing problems

Testers are paired with developersTesters are paired with developers Feature teams synchronize work by Feature teams synchronize work by

building the product, finding and fixing building the product, finding and fixing errors on a daily and weekly basiserrors on a daily and weekly basis

At the end of a subproject, the product is At the end of a subproject, the product is stabilizedstabilized

Stabilization PhaseStabilization Phase

Internal testing of complete productInternal testing of complete product External testingExternal testing

– beta sitesbeta sites– ISVsISVs– OEMsOEMs– end usersend users

Release preparationRelease preparation

Stabilization

Five PrinciplesFive Principles(used for defining products and (used for defining products and

organizing the development organizing the development process)process)

1.1.Divide large projects into multiple cycles Divide large projects into multiple cycles with buffer time (20-50%)with buffer time (20-50%)

2.2.Use a “vision statement” and outline feature Use a “vision statement” and outline feature specifications to guide projectsspecifications to guide projects

3.3.Base feature selection and priority order on Base feature selection and priority order on user activities and datauser activities and data

4.4.Evolve a modular and horizontal design Evolve a modular and horizontal design architecturearchitecture

5.5.Control by individual commitments to small Control by individual commitments to small tasks and fixed project resourcestasks and fixed project resources

Directing and ControllingDirecting and Controlling

Think about features large numbers Think about features large numbers

of customers will pay money forof customers will pay money for

Exert pressure by limiting resources Exert pressure by limiting resources

such as staffing and schedulesuch as staffing and schedule

Sequential subprojects with priority-Sequential subprojects with priority-

ordered featuresordered features

Directing and ControllingDirecting and Controlling

Modular architecture allows teams to Modular architecture allows teams to incrementally add featuresincrementally add features

After resources are fixed, features After resources are fixed, features must be deleted if teams fall behind must be deleted if teams fall behind schedule [sometimes this is very schedule [sometimes this is very difficult to do]difficult to do]

Buffer time allows response to changes Buffer time allows response to changes and unexpected difficultiesand unexpected difficulties

Five PrinciplesFive Principles(used to manage the process of (used to manage the process of

developing and shipping products)developing and shipping products)

1.1.Work in parallel teams but “synch up” and Work in parallel teams but “synch up” and debug dailydebug daily

2.2.Always have a product you can ship, with Always have a product you can ship, with versions for every major platform and marketversions for every major platform and market

3.3.Speak a “common language” on a single Speak a “common language” on a single development sitedevelopment site

4.4.Continuously test the product as you build itContinuously test the product as you build it

5.5.Use metric data to determine milestone Use metric data to determine milestone completion and product releasecompletion and product release

Rules for CoordinationRules for Coordination

Specific time to “check in” codeSpecific time to “check in” code– new build every daynew build every day– immediate testing and debuggingimmediate testing and debugging

Code that “breaks” the build must Code that “breaks” the build must be fixed immediatelybe fixed immediately

Daily builds generated for each Daily builds generated for each platform and for each market platform and for each market

CommunicationCommunication

All developers at a single physical siteAll developers at a single physical site Common development languages (C/C++)Common development languages (C/C++) Standardized development toolsStandardized development tools Small set of quantitative metrics to decide Small set of quantitative metrics to decide

when to move forward in a projectwhen to move forward in a project– e.g. daily build progress is tracked by the e.g. daily build progress is tracked by the

number of new, resolved and active bugsnumber of new, resolved and active bugs

The “Structured Hacker” The “Structured Hacker” ApproachApproach

Retain hacker culture Retain hacker culture Add enough structure to make Add enough structure to make

products reliable enough, powerful products reliable enough, powerful enough, and simple enoughenough, and simple enough

Support a competitive strategy of Support a competitive strategy of introducing products that are “good introducing products that are “good enough”, and improving them by enough”, and improving them by incrementally evolving featuresincrementally evolving features

Comparison to Comparison to Traditional ApproachTraditional Approach

Waterfall approach “freezes” product Waterfall approach “freezes” product specification, then all components specification, then all components are designed, built and merged.are designed, built and merged.

Prevents Prevents – changing specificationschanging specifications– getting feedback from customersgetting feedback from customers– continually testing components as the continually testing components as the

product evolvesproduct evolves

Advantages of Advantages of Synch-and-StabilizeSynch-and-Stabilize

Lends itself toLends itself to

– shipping preliminary versionsshipping preliminary versions

– adding features or in subsequent adding features or in subsequent

releasesreleases

– easier integration of pieces of easier integration of pieces of

products that may still be years awayproducts that may still be years away

Synch-&-Stabilize versus Synch-&-Stabilize versus SequentialSequential

Parallel development Parallel development & testing& testing

Vision statement and Vision statement and evolving specificationevolving specification

Features prioritized Features prioritized in subprojectsin subprojects

Daily builds (synch), Daily builds (synch), intermediate intermediate stabilizationsstabilizations

Sequential Sequential development & testing development & testing

Frozen specificationFrozen specification

All features built All features built simultaneouslysimultaneously

One late, large One late, large integration and test integration and test phase at the endphase at the end

Synch-&-Stabilize versus Synch-&-Stabilize versus SequentialSequential

Fixed, multiple Fixed, multiple

release & ship datesrelease & ship dates

Continuous customer Continuous customer

feedback in feedback in

development processdevelopment process

Large teams work like Large teams work like

small teamssmall teams

Aiming for perfection Aiming for perfection in each cyclein each cycle

Feedback after Feedback after development as development as input for next input for next projectproject

Individuals in Individuals in separate functional separate functional departments work departments work as a large groupas a large group

WeaknessesWeaknesses Microsoft needs more concentrated focus on its Microsoft needs more concentrated focus on its

product architecturesproduct architectures Microsoft needs a more rigorous approach to Microsoft needs a more rigorous approach to

design & code reviewsdesign & code reviews S-&-S process may not be suitable for all new S-&-S process may not be suitable for all new

productsproducts– e.g., Video on demand components have real-time e.g., Video on demand components have real-time

constraints that require precise mathematical modelsconstraints that require precise mathematical models Cannot test the infinite number of potential user Cannot test the infinite number of potential user

scenariosscenarios Does not focus on defect preventionDoes not focus on defect prevention

BenefitsBenefits

Breaks down large projects into Breaks down large projects into

manageable pieces (priority-ordered manageable pieces (priority-ordered

sets of features)sets of features)

Projects proceed systematically even Projects proceed systematically even

when it’s impossible to complete a when it’s impossible to complete a

stable design at the outsetstable design at the outset

Large teams work like small teamsLarge teams work like small teams

More BenefitsMore Benefits

Provides a mechanism for customer Provides a mechanism for customer inputs, setting priorities, completing inputs, setting priorities, completing most important parts firstmost important parts first

Allows responsiveness to the Allows responsiveness to the marketplace by “always” having a marketplace by “always” having a product ready to ship and having an product ready to ship and having an accurate assessment of which accurate assessment of which features are completedfeatures are completed

Who can benefit?Who can benefit?

Fast-paced marketsFast-paced markets Complex products with short life Complex products with short life

cyclescycles Products that compete on the basis Products that compete on the basis

of evolving featuresof evolving features Products that need to support “de Products that need to support “de

facto” standardsfacto” standards

(last slide)

I don't think Bill is gonna like what he finds in the road

ahead....

For those of youwho don’t know…this is the Coverof Bill Gates book!

(without the JavaCoffee Cup!)