Microsoft Memo
To: Application developers and testers
From: Chris Mason
Date: 6/20/89
Subject: Zero-defects code
Cc: Mike Maples, Steve Ballmer, Applications Business Unit managers and department heads
"On May 12th and 13th, the applications development managers held a retreat with some of their project leads, Mike Maples, and other representatives of Applications and Languages. My discussion group investigated techniques for writing code with no defects. This memo describes the conclusions which we reached.... There are a lot of reasons why our products seem to get buggier and buggier. It's afact that they're getting more complex, but we haven't changed our methods to respond to that complexity....
The point of enumerating our problems is to realize that our current methods, not our people, cause their own failure.... Our scheduling methods and Microsoft's culture encourage doing the minimum work necessary on a feature. When it works well enough to demonstrate, we consider it done, everyone else considers it done, and the feature is checked off the schedule. The inevitable bugs months later are seen as unrelated.... When the schedule is jeopardized, we start cutting corners.... The reason that complexity breeds bugs is that we don't understand how he pieces will work together. This is true for new products as well as for changes of existing products.... I mean this literally: your goal should be to have a working, nearly-shippable product every day.... Since human beings themselves are not fully debugged yet, there will be bugs in your code no matter what you do. When this happens, you must evaluate the problem and resolve it immediately.... Coding is the major way we spend our time. Writing bugs means we're failing in our major activity. Hundreds of thousands of individuals and companies rely on our products; bugs can cause a lot of lost time and money. We could conceivably put a company out of business with a bug in a spreadsheet, database, or wordprocessor. We have to start taking this more seriously" (Mason, 1989).
Comments