The Microsoft Software

Development Process

Scott Guthrie
Program Manager
Microsoft Corporation
 “Natural” Phases of a
Software Project
v Enthusiasm
v Disillusionment
v Panic
v Search for the Guilty
v Punishment of the Innocent
v Praise and Honors for Non-Participants
 Successful Projects

v Not all software projects have to

progress this way!

v Those that are successful typically

share three outstanding characteristics:
À People
À Poise
À Process
 Today’s Agenda:
The Microsoft Development Process
v Origin of a MS Product
v The Product Team
v Designing the Product
v Scheduling the Product
v Implementing the Product
v Testing the Product
v Shipping the Product
Origin of a MS Product
 How to Start a MS Product
v Step 1: Identify market opportunity
À Customers, Competitors, Market Dynamics

v Step 2: Determine viability of market entry

À Volume, price/cost margins, fixed costs, etc.

v Step 3: Define vision statement

À Crisp enunciation of goals + issue ownership
À Explain strategic importance to company

v Step 4: Make a lot of noise!

The Product Team
 The Product Team
Product Unit Manager

Dev Manager Group Program Manager Test Manager

Dev Lead PM Lead Test Lead

Dev Lead PM Lead Test Lead

Dev PM Tester

Dev PM Tester
Designing the Product
 Product Design
v Thoroughly understand your customers
À How do they work? What do they really do?
À Visit, observe, listen & meticulously document

v Thoroughly understand your competitors

À Evaluate their product strengths/weaknesses?

v Identify the strategic and tactical themes

and requirements that your features
should be thinking about
À Ensure that they are inline w/ vision statement
 Feature Design
v Drill down on feature specifics
À Focus on “what it does” vs. “how we build it”

v Questions to consider:
À How do we make a feature usable/simple?
À How do we make a feature visible?
À How do we integrate other parts of a product?

v Document scenarios, assumptions and

design proposal in a detailed spec
À Maintain tight feedback/evaluation loop
 Implementation Issues
v Developers own thinking through the
implementation issues of a feature

v Questions to consider:
À How factorable is the feature?
À Can the feature be delivered in stages?
À What dependencies does it have?
À What other features are dependent on it?
À How many developer weeks are required?
Scheduling the Product
 Scheduling/Planning
v Schedules are done after the initial design
document is ready for review

v There is an inherit tension between the

schedule and the design document
À Each needs to be constantly re-evaluated and
re-calibrated against the other

v Software scheduling in general is

something of an imprecise science
À Concatenation of educated guesses
 Scheduling Questions
v Is the ship date driven by features or a
hard schedule?
v Can/should the product vision be staged
over multiple product releases?
v How long has the product team worked
together? What size will it be?
À Big != Good. Keep in mind the N-1 rule...

v Will the team be working at a normal pace

or in “Death-March” mode?
 Milestones
v Milestones are used to logically segment
development into 9-12 week periods
À Early Milestones: Critical features & core code
À Later Milestones: Functionality that can be cut

v Milestones help maintain “ship-mode”

focus/atmosphere over long projects

v Milestones encourage staging of products

À Enable review of progress (“Postmortems”)
À Facilitate corrections to master schedule
 Rules for Picking Dates
v Whatever date you publish will be the
earliest you possibly ship
À Date should be aggressive and realistic

v Budget vacations and sick-leave

v Plan for unexpected absences

À maternity/paternity leave

v Pad schedule for stabilization and non-

deterministic progress delays
Implementing the Product
 Establish Best Practices
v Source code management
À Whatever happened to Microsoft Pascal?

v Coding Standards
À What dialect of Hungarian do you use?

v Code Reviews
À Every line of code should be peer reviewed

v Localization Guidelines
À If you plan ahead it is money in the bank…
 First Implementation Steps
v Define overall code-base structure:
À Specify directory hierarchy (headers, libs, etc.)
À Setup Makefile and build environment
À Come up with common Macros and Ifdefs

v Define overall code-base architecture:

À Design core APIs, interfaces and structures
 Builds
v Products are compiled and released daily
À Forcing factor for code interoperation
À Provides steady progress measurement
À Enables daily test coverage of entire product

v Builds can often take a long time…

À “Clean Build” of Windows NT takes 36 hours

v It is critical that delays are minimized

À Strict check-in procedures typically enforced
 Check-in Procedures
v Step 1: Finish writing code

v Step 2: Code review with a team member

v Step 3: “Buddy build” on 2 clean systems

v Step 4: Send “check-in request” mail to the

Build Technician and daily “Build Meister”

v Step 5: If check-in is approved, the build

technician will check-out appropriate files
into the build tree
 Build Problems
v Build Breaks (compile/linking error)
À Basically means some bozo screwed up
À Punishment should fit the crime… :-)

v Build Verification Test (BVT) Failures

À Automated test indicates functionality failure

v Each build classified at release:

À “Self Host”
À “Self Test”
À “Self Toast”
Ensuring Product Quality
 Software Testing
v Testing is critical to software development
À Must be analytical, methodical and thorough

v Test plan documents must be developed

before code is even written

v Automation is key to stabilizing a product

À Comprehensive code coverage
À Enables quick verification of product health
À Enables easy reproducibility of errors
 Bug Triage
v Discovered bugs are logged to a database

v Senior team members meet at least once a

day to review/rank active bugs

v Bugs assigned severity, priority, owner

À Must-fix bugs marked as “showstoppers”

v “Scrubbing” the bug list

À Process of upgrading bugs to future releases
À Done when a bug is just too dangerous to fix
Getting It Out The Door
 The End Game
v Alpha Release
v Beta1 Release
v Code Complete
v Beta2 Release
v Zero Bug-Bounce
v Release Candidate (RC)
v Release to Manufacturing (RTM)
End Game Responsibilities
v Program Management: Ensure that all
scenarios documented in design spec
are fully operational.

v Test: Ensure that all features

implemented are at 0 showstoppers.

v Development: Resolve critical bugs as

they appear. Ensure that the build
remains stable
 The End
v Once the build hits zero showstoppers, it
will be “escrowed” while the team spends
several days verifying that no new nasty
bugs are lurking.

v If no new showstopper bugs are identified,

a “master” or “golden” CD will be burned
with the product bits.

v The CD will then be released to a

manufacturing factory where shrink-
wrapped products will be produced.