MSBuild - How Microsoft Builds Software How Microsoft...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: How Microsoft Builds Software* 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. The Challenges The Challenges s Quality problems s Delayed deliveries s Larger development teams – Win 95 had over 200 programmers and testers s Software products with millions of lines of source code – 11+ million lines of code in Win 95 s Development lasting one or more years Product Complexity Product Complexity s s s s 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 The need for iterations The need for iterations Users’ needs are difficult to understand s Software/hardware changes rapidly s It is difficult to design a software system completely in advance s Similar to the spiral model and other iterative enhancement development processes s Scaling up a flexible, Scaling up a flexible, entrepreneurial company s Small team style (3­8 developers) s Many parallel teams s Freedom to evolve designs s Synchronize frequently Synch­and­Stabilize Approach Synch­and­Stabilize Approach Continually synchronize parallel teams s Periodically stabilize the product in increments versus once at the end s Also known as: s – milestone process – daily build process – nightly build process – zero­defect process Overview of Overview of Synch­and­Stabilize Development Planning Development Stabilization Planning Phase Planning Phase Planning Vision Statement ­ Product Managers s Define goals for the new product s Priority­order user activities that need to be supported by product features s Deliverables: s – Specification document – Schedule and “feature” team formation 1 program manager s 3­8 developers s 3­8 testers (1:1 ratio with developers) s Development Phase Development Phase Development 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 s Subprojects ­­ design, code, debug s – starting with most critical features and shared components – feature set may change by 30% or more Subproject Development Subproject Development Feature teams go through the complete cycle of development, feature integration, testing and fixing problems s Testers are paired with developers s Feature teams synchronize work by building the product, finding and fixing errors on a daily and weekly basis s At the end of a subproject, the product is stabilized s Stabilization Phase Stabilization Phase Stabilization Internal testing of complete product s External testing s – beta sites – ISVs – OEMs – end users s Release preparation Five Principles 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 Directing and Controlling Directing and Controlling s s s 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 Directing and Controlling Directing and Controlling s s s 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 Five Principles 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 Rules for Coordination Rules for Coordination s Specific time to “check in” code – new build every day – immediate testing and debugging Code that “breaks” the build must be fixed immediately s Daily builds generated for each platform and for each market s Communication Communication s All developers at a single physical site s Common development languages (C/C++) s Standardized development tools s 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 The “Structured Hacker” Approach The “Structured Hacker” Approach Retain hacker culture s Add enough structure to make products reliable enough, powerful enough, and simple enough s Support a competitive strategy of introducing products that are “good enough”, and improving them by incrementally evolving features s Comparison to Comparison to Traditional Approach Waterfall approach “freezes” product specification, then all components are designed, built and merged. s Prevents s – changing specifications – getting feedback from customers – continually testing components as the product evolves Advantages of Advantages of Synch­and­Stabilize s Lends itself to – shipping preliminary versions – adding features or in subsequent releases – easier integration of pieces of products that may still be years away Synch­&­Stabilize versus Synch­&­Stabilize versus Sequential s s s s Parallel development & testing Vision statement and evolving specification Features prioritized in subprojects Daily builds (synch), intermediate stabilizations s s s s Sequential development & testing Frozen specification All features built simultaneously One late, large integration and test phase at the end Synch­&­Stabilize versus Synch­&­Stabilize versus Sequential s s Fixed, multiple release & ship dates Continuous customer feedback in development process s Large teams work like small teams s s s Aiming for perfection in each cycle Feedback after development as input for next project Individuals in separate functional departments work as a large group Weaknesses Weaknesses Microsoft needs more concentrated focus on its product architectures s Microsoft needs a more rigorous approach to design & code reviews s S­&­S process may not be suitable for all new products s – e.g., Video on demand components have real­time constraints that require precise mathematical models Cannot test the infinite number of potential user scenarios s Does not focus on defect prevention s Benefits Benefits s s s 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 More Benefits More Benefits Provides a mechanism for customer inputs, setting priorities, completing most important parts first s Allows responsiveness to the marketplace by “always” having a product ready to ship and having an accurate assessment of which features are completed s (last slide) Who can benefit? Who can benefit? Fast­paced markets s Complex products with short life cycles s Products that compete on the basis of evolving features s Products that need to support “de facto” standards s 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!) ...
View Full Document

{[ snackBarMessage ]}

Ask a homework question - tutors are online