Zero-defects code: the prescient Microsoft memo from 1989 — Digital Seams
Open Menu<br>Close Menu
Digital Seams
Open Menu<br>Close Menu
Zero-defects code: the prescient Microsoft memo from 1989
Jul 5
Written By Bobbie Chen
“We are not suggesting this is attainable on the first try, but we think we know how to get there.”<br>There are no new ideas in software engineering, only ones we’ve learned and then forgotten. In 1989, the Zero Defects memo at Microsoft was already arguing for the ideas that became Continuous Integration, Test-Driven Development, and “shift left”.
In 1989, Microsoft had shipped MS-DOS but hadn’t made it to Windows 3.1 yet. The team was behind schedule and buried in bugs on the projects that would become Microsoft Access and Microsoft Word; it was common to “death march” as deadlines approached, working long hours for months to try and fix all the issues. But engineering leader Chris Mason argued that “perfect” code which conforms to its requirements was possible:<br>You can improve the quality of your code, and if you do, the rewards for yourself and for Microsoft will be immense. The hardest part is to decide that you want to write perfect code.
As Steven Sinofsky writes about the corporate culture at the time, “We were rewarding developers for checking in new code and declaring it done, even if it was not.” The memo was a response to that dysfunction.<br>Zero Defects is shockingly forward-looking for a 1989 memo, or alternatively a reminder that all software engineering has already been figured out before. Unfortunately, I’ve heard plenty of stories about companies who could use this advice today!<br>It’s got continuous integration and delivery:<br>I mean this literally: your goal should be to have a working, nearly-shippable product every day.
It’s got test-driven development:<br>Before you start debugging, determine what you’ll be looking for and write it down. If you can automate the tests, better yet.”
It’s got the core of shift left:<br>Speed with quality is a worthy goal, but quality usually suffers. Evidence suggests that you can spend your time thinking about side-effects and planning up front, or you can spend it patching fixes to bugs later on.
Some things don’t change. My favorite part of Zero Defects is that engineering leaders commit their political support for individual contributors to push back:<br>Don’t give in. Your first schedules will look infinitely padded, when in fact they will simply be true (a new thing in the world). Mike Maples has agreed to stand behind any schedule that can be defended as realistic.<br>If problems do occur, slip the schedule. Your goal should be to keep the schedule realistic (descriptive as well as prescriptive). It’s better to take the little heat now than the nova later on.
The full memo is below, as transcribed from Steven Sinofsky’s Hardcore Software - where I first heard about it. The full book is worth the read!
Microsoft Memo<br>To: Applications developers and testers<br>From: Chris Mason<br>Date: 6/20/89<br>Subject: Zero-defects code<br>Cc: Mike Maples, Steve Ballmer, Applications Business Unit managers and department heads<br>Zero defects<br>On May 12th and 13th, the application development managers held a retreat with some of their project leads, Mike Maples, and other representatives of Applications and Languages. My discussion group[1] investigated techniques for writing code with no defects. This memo describes the conclusions we reached.<br>Zero-defects code is the Holy Grail of programming. We are not suggesting that this phantasm is attainable on the first try, but we think we know how to get there. There is a crucial need to do this. In OBU, for example, Mac and PC Word were very late, and Win Word continues to be late, in each case because we had many more bugs than we anticipated. Large numbers of bugs at the end of a project make scheduling impossible for project leads and life unbearable for programmers and testers.<br>Zero defects has actually been achieved on software projects; it is not an impossible goal. Zero defects must be the new performance standard for development. A “defect” occurs when something that is labeled “done” does not conform to the requirements. We need to understand our methods, and strive to improve them in order to prevent defects from happening, or recover from them if they do happen. You’ll be able to measure your success by the reduced time from code complete to shipping.<br>You can improve the quality[2] of your code, and if you do, the rewards for yourself and for Microsoft will be immense. The hardest part is to decide that you want to write perfect code.<br>The problem<br>There are a lot of reasons why our products seem to get buggier and buggier. It’s a fact that they’re getting more complex, but we haven’t changed our methods to respond to that complexity.<br>The problems listed below are not an indictment. Some programmers write perfect code today, and the rest of us have good, honest reasons for coding the way we do. The point of...