{ "docId": "019f6b8f-8159-75fd-8b94-b1032b0be29d", "docSlug": "jarvis-zero-defects-code", "documentTitle": "zero defects code", "authorId": "zero-defects-code", "authorName": null, "documentKindSlug": "deck", "documentKindLabel": "Deck", "sourceTypeSlug": "investor_relations", "sourceTypeLabel": "Investor relations", "presentationDate": null, "orientation": null, "aspectRatio": null, "pageNumber": 3, "pageCount": 10, "prevPage": 2, "nextPage": 4, "slideType": "problem_statement", "function": "frame_problem", "density": "overcrowded", "nDataPoints": 0, "notes": "This appears to be a page from a technical whitepaper or internal Microsoft document regarding software quality.", "elementsJson": null, "metadataConfidence": 0.9, "imagePath": null, "slideHref": "/slides/019f6b8f-8159-75fd-8b94-b1032b0be29d/3", "deckHref": "/decks/019f6b8f-8159-75fd-8b94-b1032b0be29d", "deckJsonHref": "/decks/019f6b8f-8159-75fd-8b94-b1032b0be29d.json", "deckAnchorHref": "/decks/019f6b8f-8159-75fd-8b94-b1032b0be29d#slide-3", "components": [ { "bbox": { "h": 0.02, "w": 0.72, "x": 0.14, "y": 0.95 }, "kind": "other", "text": "Zero-defects code — 3 — Microsoft", "attrs": null, "subkind": "other", "toolName": null, "toolSlug": null, "confidence": null, "componentId": "669e9d4d-6cbc-40d8-8fba-fece2b4f61a3", "frameworkName": null, "frameworkSlug": null }, { "bbox": { "h": 0.05, "w": 0.72, "x": 0.14, "y": 0.86 }, "kind": "paragraph", "text": "Fix it now\nSince 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", "attrs": null, "subkind": "paragraph", "toolName": null, "toolSlug": null, "confidence": null, "componentId": "3f8467b6-15da-4623-94e0-ca589e08efbb", "frameworkName": null, "frameworkSlug": null }, { "bbox": { "h": 0.12, "w": 0.72, "x": 0.14, "y": 0.51 }, "kind": "paragraph", "text": "First, I have to admit that there is no single solution. Every project team must evaluate itself and its product and determine what will help to achieve zero defects. It doesn’t matter whether we can actually achieve zero on the first attempt, but we should start right now and get closer on every project.\nThis section gives a broad overview of the solution. The following sections describe how to change your attitudes and work habits to reach that goal. A few of the ideas must be done or the whole thing will collapse, but for the most part each project should pick and choose what works best for them.", "attrs": null, "subkind": "paragraph", "toolName": null, "toolSlug": null, "confidence": null, "componentId": "4772e075-1543-451e-86eb-8ec072b600e7", "frameworkName": null, "frameworkSlug": null }, { "bbox": { "h": 0.22, "w": 0.72, "x": 0.14, "y": 0.64 }, "kind": "paragraph", "text": "Zero bugs every day\nI mean this literally: your goal should be to have a working, nearly-shippable product every day.\nThis doesn’t mean that when you go home every night you have removed all the bugs from work in progress. It simply means that when a programmer says a feature is complete, it is totally complete: all error and boundary cases work, all interactions with the rest of the product have been dealt with, test documentation or code to exercise the feature are checked in.\nYour project should have a state or directory from which anyone can create a current “clean” copy of the product. One way to handle this is to stage the checkin. Modules can be checked in to a “working” directory for history and as insurance against hard disk failure, then checked in to the “clean” directory when the feature is complete.", "attrs": null, "subkind": "paragraph", "toolName": null, "toolSlug": null, "confidence": null, "componentId": "7fa25272-457f-46eb-9de5-c16968c2b71d", "frameworkName": null, "frameworkSlug": null }, { "bbox": { "h": 0.14, "w": 0.72, "x": 0.14, "y": 0.33 }, "kind": "paragraph", "text": "“Bugs are inevitable”\nThis is an insidious idea. The fact that we must rid ourselves of this idea seems to contradict the implications I’ve been making, namely that we should anticipate bugs in our code and winnow them out early. There is no contradiction: when everyone feels that bugs will happen no matter what we do, we stop taking action to prevent any bugs from appearing.\nIn fact, bugs are inevitable. But if we act that way, we make it more horribly true.", "attrs": null, "subkind": "paragraph", "toolName": null, "toolSlug": null, "confidence": null, "componentId": "abb11704-c0f1-493c-8e7b-7165f1a56173", "frameworkName": null, "frameworkSlug": null }, { "bbox": { "h": 0.12, "w": 0.72, "x": 0.14, "y": 0.21 }, "kind": "paragraph", "text": "Over-confidence\nThis is perfectly natural, but wrong. Every programmer I know writes good code, looks at it in satisfaction, and declares that it should work. I have rarely seen new code that does so. (The occasions are easy to spot: people dancing and hooting in the halls.) What piece of code has withstood six months of testing with no bugs reported? Or been reviewed in the next version without a shudder?", "attrs": null, "subkind": "paragraph", "toolName": null, "toolSlug": null, "confidence": null, "componentId": "c7e7a7ec-d227-4ed1-b88e-85d461c29a63", "frameworkName": null, "frameworkSlug": null }, { "bbox": { "h": 0.12, "w": 0.72, "x": 0.14, "y": 0.09 }, "kind": "paragraph", "text": "Lack of ownership\nUnder pressure, we tend to hunker down and just try to get our part of the job done. But part of the job is to stand up and look around. Each developer should take the responsibility to consider the entire product, use common sense, and not just take the spec as gospel.", "attrs": null, "subkind": "paragraph", "toolName": null, "toolSlug": null, "confidence": null, "componentId": "cd0ea65a-9919-4954-ba87-0845efd127e6", "frameworkName": null, "frameworkSlug": null }, { "bbox": { "h": 0.02, "w": 0.15, "x": 0.14, "y": 0.48 }, "kind": "title", "text": "The solution", "attrs": null, "subkind": "headline", "toolName": null, "toolSlug": null, "confidence": null, "componentId": "d62f1376-b031-449d-b8e7-8f793fd9d9ef", "frameworkName": null, "frameworkSlug": null } ], "metrics": [], "tools": [], "frameworks": [], "arcBeats": [ { "to": 3, "from": 3, "beatId": "e83f106a-11b6-4c2e-810b-1b0f7866cf87", "arcName": "Problem-Agitate-Solution", "arcSlug": "problem-agitate-solution", "beatName": "Problem", "beatSlug": "problem-agitate-solution-problem-identify-pain", "evidence": "The problem statement is presented on page 3.", "position": 0, "confidence": 0.8, "parentBeatName": "Complication", "parentBeatSlug": "complication" } ], "loops": [ { "to": 4, "from": 3, "name": "Cost Of Inaction", "slug": "27-cost-of-inaction", "bestFor": "Urgent budget requests, compliance, risk mitigation", "matchId": "dd0149d9-43f0-4c89-9018-c58b0a12efa6", "evidence": "The problem statement and key messages imply a cost of inaction.", "position": 0, "objective": "What are the costs of not achieving zero defects?", "structure": "The Status Quo -> The Hidden Costs Accumulating -> The Future State of Inaction -> The Tipping Point", "confidence": 0.6, "description": "Quantify what happens if the audience does nothing" } ], "imagePathAlt": null, "thumbSrc": null, "thumbSrcAlt": null, "locked": true }