How Microsoft Builds Software*

1. How Microsoft Builds Software* Presented by: Ron Norman Society for Software Quality June 23, 1998 Michael A. Cusumano Professor of Strategy & Technology Management Sloan School of Management Massachusetts Institute of Technology Richard W. Selby Associate Professor of Computer Science Department of Information & Computer Science University of California, Irvine * Adapted from “How Microsoft Builds Software”, Communications of the ACM, June 1997, Vol. 40. No. 6, pp. 53-61. This article is based on the author’s book: Microsoft Secrets: How the World’s Most Powerful Software Company Creates Technology, Shapes Markets, and Manages People, The Free Press/Simon & Schuster, New York, 1995.

2. The Challenges • Quality problems • Delayed deliveries • Larger development teams • Win 95 had over 200 programmers and testers • Software products with millions of lines of source code • 11+ million lines of code in Win 95 • Development lasting one or more years

3. Product Complexity • Components are interdependent • Components are difficult to define in early stages of the development cycle • Need to proceed with coordination, while allowing flexibility to be creative • Need a mechanism to test the product with customers and refine the designs during the development process

4. The need for iterations • Users’ needs are difficult to understand • Software/hardware changes rapidly • It is difficult to design a software system completely in advance • Similar to the spiral model and other iterative enhancement development processes

5. Scaling up a flexible, entrepreneurial company • Small team style (3-8 developers) • Many parallel teams • Freedom to evolve designs • Synchronize frequently

6. Synch-and-Stabilize Approach • Continually synchronize parallel teams • Periodically stabilize the product in increments versus once at the end • Also known as: • milestone process • daily build process • nightly build process • zero-defect process

7. Overview of Synch-and-Stabilize Development Planning Development Stabilization

8. Planning Planning Phase • Vision Statement - Product Managers • Define goals for the new product • Priority-order user activities that need to be supported by product features • Deliverables: • Specification document • Schedule and “feature” team formation • 1 program manager • 3-8 developers • 3-8 testers (1:1 ratio with developers)

9. Development Development Phase • Feature development in 3-4 subprojects (lasting 2-4 months each) using functional specifications that outline product features in enough depth to organize schedules and allocate staff • Subprojects -- design, code, debug • starting with most critical features and shared components • feature set may change by 30% or more

10. Subproject Development • Feature teams go through the complete cycle of development, feature integration, testing and fixing problems • Testers are paired with developers • Feature teams synchronize work by building the product, finding and fixing errors on a daily and weekly basis • At the end of a subproject, the product is stabilized

11. Stabilization Stabilization Phase • Internal testing of complete product • External testing • beta sites • ISVs • OEMs • end users • Release preparation

12. Five Principles(used for defining products and organizing the development process) 1. Divide large projects into multiple cycles with buffer time (20-50%) 2. Use a “vision statement” and outline feature specifications to guide projects 3. Base feature selection and priority order on user activities and data 4. Evolve a modular and horizontal design architecture 5. Control by individual commitments to small tasks and fixed project resources

13. Directing and Controlling • Think about features large numbers of customers will pay money for • Exert pressure by limiting resources such as staffing and schedule • Sequential subprojects with priority-ordered features

14. Directing and Controlling • Modular architecture allows teams to incrementally add features • After resources are fixed, features must be deleted if teams fall behind schedule [sometimes this is very difficult to do] • Buffer time allows response to changes and unexpected difficulties

15. Five Principles(used to manage the process of developing and shipping products) 1. Work in parallel teams but “synch up” and debug daily 2.Always have a product you can ship, with versions for every major platform and market 3.Speak a “common language” on a single development site 4.Continuously test the product as you build it 5. Use metric data to determine milestone completion and product release

16. Rules for Coordination • Specific time to “check in” code • new build every day • immediate testing and debugging • Code that “breaks” the build must be fixed immediately • Daily builds generated for each platform and for each market

17. Communication • All developers at a single physical site • Common development languages (C/C++) • Standardized development tools • Small set of quantitative metrics to decide when to move forward in a project • e.g. daily build progress is tracked by the number of new, resolved and active bugs

18. The “Structured Hacker” Approach • Retain hacker culture • Add enough structure to make products reliable enough, powerful enough, and simple enough • Support a competitive strategy of introducing products that are “good enough”, and improving them by incrementally evolving features

19. Comparison to Traditional Approach • Waterfall approach “freezes” product specification, then all components are designed, built and merged. • Prevents • changing specifications • getting feedback from customers • continually testing components as the product evolves

20. Advantages of Synch-and-Stabilize • Lends itself to • shipping preliminary versions • adding features or in subsequent releases • easier integration of pieces of products that may still be years away

21. Parallel development & testing Vision statement and evolving specification Features prioritized in subprojects Daily builds (synch), intermediate stabilizations Sequential development & testing Frozen specification All features built simultaneously One late, large integration and test phase at the end Synch-&-Stabilize versus Sequential

22. Fixed, multiple release & ship dates Continuous customer feedback in development process Large teams work like small teams Aiming for perfection in each cycle Feedback after development as input for next project Individuals in separate functional departments work as a large group Synch-&-Stabilize versus Sequential

23. Weaknesses • Microsoft needs more concentrated focus on its product architectures • Microsoft needs a more rigorous approach to design & code reviews • S-&-S process may not be suitable for all new products • e.g., Video on demand components have real-time constraints that require precise mathematical models • Cannot test the infinite number of potential user scenarios • Does not focus on defect prevention

24. Benefits • Breaks down large projects into manageable pieces (priority-ordered sets of features) • Projects proceed systematically even when it’s impossible to complete a stable design at the outset • Large teams work like small teams

25. More Benefits • Provides a mechanism for customer inputs, setting priorities, completing most important parts first • Allows responsiveness to the marketplace by “always” having a product ready to ship and having an accurate assessment of which features are completed

26. (last slide) Who can benefit? • Fast-paced markets • Complex products with short life cycles • Products that compete on the basis of evolving features • Products that need to support “de facto” standards

27. I don't think Bill is gonna like what he finds in the road ahead.... For those of you who don’t know… this is the Cover of Bill Gates book! (without the Java Coffee Cup!)