{ "archive_path": "archive/1736784779.670267", "base_url": "dwheeler.com/essays/debugging-agans.html", "basename": "debugging-agans.html", "bookmarked_date": "2025-01-13 16:12", "canonical": { "archive_org_path": "https://web.archive.org/web/dwheeler.com/essays/debugging-agans.html", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=dwheeler.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": null }, "domain": "dwheeler.com", "downloaded_at": "2025-01-13T16:13:04.957359+00:00", "downloaded_datestr": "2025-01-13 16:13", "extension": "html", "hash": "MXM4WCX6RH2FSX6QA0XV", "history": { "archive_org": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://web.archive.org/save/https://dwheeler.com/essays/debugging-agans.html" ], "cmd_version": "8.10.1", "end_ts": "2025-01-13T16:13:59.409512+00:00", "index_texts": null, "output": "https://web.archive.org/web/20250113154249/https://dwheeler.com/essays/debugging-agans.html", "pwd": "/data/archive/1736784779.670267", "schema": "ArchiveResult", "start_ts": "2025-01-13T16:13:42.308273+00:00", "status": "succeeded" } ], "dom": [ { "cmd": [ "/usr/bin/chromium-browser", "--proxy-server=socks5://tor-socks-proxy:9150", "--disable-features=DarkMode", "--run-all-compositor-stages-before-draw", "--hide-scrollbars", "--autoplay-policy=no-user-gesture-required", "--no-first-run", "--use-fake-ui-for-media-stream", "--use-fake-device-for-media-stream", "--simulate-outdated-no-au='Tue, 31 Dec 2099 23:59:59 GMT'", "--headless=new", "--no-sandbox", "--no-zygote", "--disable-dev-shm-usage", "--disable-software-rasterizer", "--disable-sync", "--window-size=1440,2000", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "--user-data-dir=/data/personas/Default/chrome_profile", "--profile-directory=Default", "--dump-dom", "https://dwheeler.com/essays/debugging-agans.html" ], "cmd_version": "131.0.6778", "end_ts": "2025-01-13T16:13:21.059865+00:00", "index_texts": null, "output": "output.html", "pwd": "/data/archive/1736784779.670267", "schema": "ArchiveResult", "start_ts": "2025-01-13T16:13:15.063126+00:00", "status": "succeeded" } ], "favicon": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://www.google.com/s2/favicons?domain=dwheeler.com" ], "cmd_version": "8.10.1", "end_ts": "2025-01-13T16:13:09.149566+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1736784779.670267", "schema": "ArchiveResult", "start_ts": "2025-01-13T16:13:06.193347+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--head", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://dwheeler.com/essays/debugging-agans.html" ], "cmd_version": "8.10.1", "end_ts": "2025-01-13T16:13:09.379712+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1736784779.670267", "schema": "ArchiveResult", "start_ts": "2025-01-13T16:13:09.211687+00:00", "status": "succeeded" } ], "htmltotext": [ { "cmd": [ "(internal) archivebox.extractors.htmltotext", "./{singlefile,dom}.html" ], "cmd_version": "0.8.5rc51", "end_ts": "2025-01-13T16:13:35.415748+00:00", "index_texts": [ "David A. Wheeler's Review of \"Debugging\" by David J. Agans David A. Wheeler's Review of Debugging by David J. Agans March 2, 2004 It's not often you find a classic, but I think I've found\na new classic for software and computer hardware developers.\nIt's David J. Agan's Debugging: The 9 Indispensable Rules for Finding\nEven the Most Elusive Software and Hardware Problems (ISBN 0814471684).\nThis book explains the fundamentals of finding and fixing bugs\n(once a bug has been detected), rather than any particular technology.\nIt's best for developers who are novices or who are only moderately\nexperienced, but even old pros will find helpful reminders of things they\nknow they should do but forget in the rush of the moment.\nThis book will help you fix those inevitable bugs,\nparticularly if you're not a pro at debugging.\nIt's hard to bottle experience; this book does a good job.\nThis is a book I expect to find useful many, many, years from now. The entire book revolves around the \"nine rules.\"\nAfter the typical introduction and list of the rules,\nthere's one chapter for each rule.\nEach of these chapters describes the rule,\nexplains why it's a rule, and\nincludes several \"sub-rules\" that explain how to apply the rule.\nMost importantly, there are lots of \"war stories\"\nthat are both fun to read and good illustrations of\nhow to put the rule into practice. Since the whole book revolves around the nine rules, it might help\nto understand the book by skimming the rules and their sub-rules: Understand the system : Read the manual, read everything in depth,\n know the fundamentals, know the road map, understand your tools, and\n look up the details. Make it fail : Do it again, start at the beginning, stimulate the failure,\n don't simulate the failure, find the uncontrolled condition that makes\n it intermittent, record everything and find the signature of intermittent\n bugs, don't trust statistics too much, know that \"that\" can happen,\n and never throw away a debugging tool. Quit thinking and look (get data first, don't just do complicated\n repairs based on guessing):\n See the failure, see the details,\n build instrumentation in, add instrumentation on, don't be afraid to dive in,\n watch out for Heisenberg, and guess only to focus the search. Divide and conquer : Narrow the search with\n successive approximation,\n get the range, determine which side of the bug you're on,\n use easy-to-spot test patterns, start with the bad,\n fix the bugs you know about, and fix the noise first. Change one thing at a time : Isolate the key factor,\n grab the brass bar with both hands (understand what's wrong before fixing),\n change one test at a time, compare it with a good one,\n and determine what you changed since the last time it worked. Keep an audit trail : Write down what you did in what order and what\n happened as a result, understand that any detail could be the\n important one, correlate events, understand that audit trails for\n design are also good for testing, and write it down! Check the plug : Question your assumptions, start at the beginning,\n and test the tool. Get a fresh view : Ask for fresh insights\n (just explaining the problem to a mannequin may help!), tap expertise,\n listen to the voice of experience, know that help is all around you,\n don't be proud, report symptoms (not theories), and\n realize that you don't have to be sure. If you didn't fix it, it ain't fixed : Check that it's really fixed,\n check that it's really your fix that fixed it,\n know that it never just goes away by itself, fix the cause, and\n fix the process. This list by itself looks dry, but the detailed explanations and\nwar stories make the entire book come alive.\nMany of the war stories jump deeply into technical details;\nsome might find the details overwhelming, but I found that they\nwere excellent in helping the principles come alive in a practical way.\nMany war stories were about obsolete technology, but since the principle\nis the point, that isn't a problem.\nNot all the war stories are about computing; there's a funny story\ninvolving house wiring, for example.\nBut if you don't know anything about computer hardware and software,\nyou won't be able to follow many of the examples. After detailed explanations of the rules, the rest of the book\nhas a single story showing all the rules in action, a set of\n\"easy exercises for the reader\", tips for help desks, and\nclosing remarks. There are lots of good points here.\nOne that particularly\nstands out is \"quit thinking and look.\"\nToo many try to \"fix\" things based on a guess\ninstead of gathering and observing data to prove or disprove a hypothesis.\nAnother principle that stands out is\n\"if you didn't fix it, it ain't fixed;\"\nthere are several vendors I'd like to give that advice to.\nThe whole \"stimulate the failure, don't simulate the failure\" discussion\nis not as clearly explained as most of the book,\nbut it's a valid point worth understanding. I particularly appreciated Agans' discussions on intermittent\nproblems (particularly in \"Make it Fail\").\nIntermittent problems are\nusually the hardest to deal with, and the author gives straightforward\nadvice on how to deal with them.\nOne odd thing is that although he mentions Heisenberg, he never mentions\nthe term (http://www.catb.org/~esr/jargon/html/H/heisenbug.html) \"Heisenbug\" ,\na common jargon term in software development\n(a Heisenbug is a bug that disappears or alters its behavior\nwhen one attempts to probe or isolate it).\nAt least a note would've been appropriate. The back cover includes a number of endorsements, including one from\nsomebody named (http://www.slashdot.org) Rob Malda .\nBut don't worry, the book's good anyway :-). It's important to note that this is a book on debugging fundamentals, and\ndifferent than most other books related to debugging.\nThere are many other books on debugging, such as\nRichard Stallman et al's Debugging with GDB: The GNU Source-Level Debugger .\nBut these other texts usually\nconcentrate primarily on a specific technology and/or\non explaining tool commands, not on timeless debugging principles.\nA few (like Norman Matloff's (http://heather.cs.ucdavis.edu/~matoff/UnixAndC/CLanguage/Debug.htm) Guide to Faster, Less Frustrating Debugging )\nhave a few general suggestions about debugging, but are\nnothing like Agans' book.\nThere are many books on testing, like\nBoris Beizer's Software Testing Techniques , but they\ntend to emphasize how to create tests to detect bugs, and\nless on how to fix a bug once it's been detected.\nOf course, once you find a bug, you should add a test for that bug\nin your regression test suite, but testing (including regression testing)\nis outside the scope of Agans' book.\nAgans' book concentrates on the big picture for debugging;\nthese other books are complementary to it. Debugging has an accompanying website at (http://www.debuggingrules.com) http://www.debuggingrules.com ,\nwhere you can find various little extras and links to related information.\nIn particular, the website has an amusing poster of the nine rules\nyou can download and print. No book's perfect, so here are my gripes and wishes: The sub-rules are really important for understanding the rules, but\nthere's no \"master list\" in the book or website that shows all the\nrules and sub-rules on one page. The end of the chapter about\na given rule summarizes the sub-rules for that one rule, but \nit'd sure be easier to have them all in one place.\nSo, print out the list of sub-rules above after you've read the book. The book left me wishing for more detailed suggestions about specific\ncommon technology.\nThis is probably unfair, since the author is trying to\ngive timeless advice rather than a \"how to use tool X\" tutorial.\nBut it'd be very useful to give\ngood general advice, specific suggestions, and examples of what approaches\nto take for common types of tools\n(like symbolic debuggers, digital logic probes, etc.), specific\nwidely-used tools (like ddd on gdb), and common problems.\nEven after the specific tools are gone, such advice can help you use\nlater ones.\nA little of this is hinted at in the \"know your tools\" section, but\nI'd like to have seen much more of it.\nVendors often crow about what their tools can do, but rarely\nexplain their weaknesses or how to apply them in a broader context. There's probably a need for another book that takes the same rules,\nbut broadens them to solving arbitrary problems.\nFrankly, the rules apply to many situations beyond computing, but the\nwar stories are far too technical for the non-computer person to\nunderstand. But as you can tell, I think this is a great book.\nIn some sense, what it says is \"obvious,\" but it's only obvious\nas all fundamentals are obvious.\nMany sports teams know the fundamentals, but fail to consistently\napply them - and fail because of it.\nNovices need to learn the fundamentals, and pros need occasional\nreminders of them; this book is a good way to learn or be reminded of them.\nGet this book. (http://www.slashdot.org) Slashdot posted (http://books.slashdot.org/article.pl?sid=04/02/21/228241) an earlier version of this review on February 24, 2004. (https://dwheeler.com) David A. Wheeler is\nan expert on (https://dwheeler.com/secure-programs) developing secure\nprograms and (https://dwheeler.com/oss_fs_why.html) quantitative\nanalysis of open source software / Free Software .\nHe lives in Northern Virginia. " ], "output": "htmltotext.txt", "pwd": "/data/archive/1736784779.670267", "schema": "ArchiveResult", "start_ts": "2025-01-13T16:13:35.399110+00:00", "status": "succeeded" } ], "media": [ { "cmd": [ "/usr/local/bin/yt-dlp", "--restrict-filenames", "--trim-filenames", "128", "--write-description", "--write-info-json", "--write-annotations", "--write-thumbnail", "--no-call-home", "--write-sub", "--write-auto-subs", "--convert-subs=srt", "--yes-playlist", "--continue", "--no-abort-on-error", "--ignore-errors", "--geo-bypass", "--add-metadata", "--format=(bv*+ba/b)[filesize<=750m][filesize_approx<=?750m]/(bv*+ba/b)", "--skip-download", "--cache-dir=/data/yt-dlp-cache/", "--cookies=/data/yt-dlp-cache/cookies.txt", "--proxy=socks5://tor-socks-proxy:9150", "--no-playlist", "https://dwheeler.com/essays/debugging-agans.html" ], "cmd_version": "2024.10.7", "end_ts": "2025-01-13T16:13:42.168108+00:00", "index_texts": [], "output": "media/", "pwd": "/data/archive/1736784779.670267", "schema": "ArchiveResult", "start_ts": "2025-01-13T16:13:37.350200+00:00", "status": "succeeded" } ], "mercury": [ { "cmd": [ "/home/archivebox/.npm/bin/postlight-parser", "https://dwheeler.com/essays/debugging-agans.html" ], "cmd_version": "2.2.3", "end_ts": "2025-01-13T16:13:35.372544+00:00", "index_texts": null, "output": "mercury/", "pwd": "/data/archive/1736784779.670267", "schema": "ArchiveResult", "start_ts": "2025-01-13T16:13:33.059147+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/home/archivebox/.npm/bin/readability-extractor", "/tmp/tmp_5p8_iiu", "https://dwheeler.com/essays/debugging-agans.html" ], "cmd_version": "0.0.11", "end_ts": "2025-01-13T16:13:24.524083+00:00", "index_texts": [ "March 2, 2004\n\n\n\n\n\nIt's not often you find a classic, but I think I've found\na new classic for software and computer hardware developers.\nIt's David J. Agan's\nDebugging: The 9 Indispensable Rules for Finding\nEven the Most Elusive Software and Hardware Problems\n(ISBN 0814471684).\nThis book explains the fundamentals of finding and fixing bugs\n(once a bug has been detected), rather than any particular technology.\nIt's best for developers who are novices or who are only moderately\nexperienced, but even old pros will find helpful reminders of things they\nknow they should do but forget in the rush of the moment.\nThis book will help you fix those inevitable bugs,\nparticularly if you're not a pro at debugging.\nIt's hard to bottle experience; this book does a good job.\nThis is a book I expect to find useful many, many, years from now.\n\n\nThe entire book revolves around the \"nine rules.\"\nAfter the typical introduction and list of the rules,\nthere's one chapter for each rule.\nEach of these chapters describes the rule,\nexplains why it's a rule, and\nincludes several \"sub-rules\" that explain how to apply the rule.\nMost importantly, there are lots of \"war stories\"\nthat are both fun to read and good illustrations of\nhow to put the rule into practice.\n\n\nSince the whole book revolves around the nine rules, it might help\nto understand the book by skimming the rules and their sub-rules:\n\nUnderstand the system: Read the manual, read everything in depth,\n know the fundamentals, know the road map, understand your tools, and\n look up the details.\nMake it fail: Do it again, start at the beginning, stimulate the failure,\n don't simulate the failure, find the uncontrolled condition that makes\n it intermittent, record everything and find the signature of intermittent\n bugs, don't trust statistics too much, know that \"that\" can happen,\n and never throw away a debugging tool.\nQuit thinking and look (get data first, don't just do complicated\n repairs based on guessing):\n See the failure, see the details,\n build instrumentation in, add instrumentation on, don't be afraid to dive in,\n watch out for Heisenberg, and guess only to focus the search.\nDivide and conquer: Narrow the search with\n successive approximation,\n get the range, determine which side of the bug you're on,\n use easy-to-spot test patterns, start with the bad,\n fix the bugs you know about, and fix the noise first.\nChange one thing at a time: Isolate the key factor,\n grab the brass bar with both hands (understand what's wrong before fixing),\n change one test at a time, compare it with a good one,\n and determine what you changed since the last time it worked.\nKeep an audit trail: Write down what you did in what order and what\n happened as a result, understand that any detail could be the\n important one, correlate events, understand that audit trails for\n design are also good for testing, and write it down!\nCheck the plug: Question your assumptions, start at the beginning,\n and test the tool.\nGet a fresh view: Ask for fresh insights\n (just explaining the problem to a mannequin may help!), tap expertise,\n listen to the voice of experience, know that help is all around you,\n don't be proud, report symptoms (not theories), and\n realize that you don't have to be sure.\nIf you didn't fix it, it ain't fixed: Check that it's really fixed,\n check that it's really your fix that fixed it,\n know that it never just goes away by itself, fix the cause, and\n fix the process.\n\n\n\nThis list by itself looks dry, but the detailed explanations and\nwar stories make the entire book come alive.\nMany of the war stories jump deeply into technical details;\nsome might find the details overwhelming, but I found that they\nwere excellent in helping the principles come alive in a practical way.\nMany war stories were about obsolete technology, but since the principle\nis the point, that isn't a problem.\nNot all the war stories are about computing; there's a funny story\ninvolving house wiring, for example.\nBut if you don't know anything about computer hardware and software,\nyou won't be able to follow many of the examples.\n\n\nAfter detailed explanations of the rules, the rest of the book\nhas a single story showing all the rules in action, a set of\n\"easy exercises for the reader\", tips for help desks, and\nclosing remarks.\n\n\nThere are lots of good points here.\nOne that particularly\nstands out is \"quit thinking and look.\"\nToo many try to \"fix\" things based on a guess\ninstead of gathering and observing data to prove or disprove a hypothesis.\nAnother principle that stands out is\n\"if you didn't fix it, it ain't fixed;\"\nthere are several vendors I'd like to give that advice to.\nThe whole \"stimulate the failure, don't simulate the failure\" discussion\nis not as clearly explained as most of the book,\nbut it's a valid point worth understanding.\n\n\nI particularly appreciated Agans' discussions on intermittent\nproblems (particularly in \"Make it Fail\").\nIntermittent problems are\nusually the hardest to deal with, and the author gives straightforward\nadvice on how to deal with them.\nOne odd thing is that although he mentions Heisenberg, he never mentions\nthe term\n\"Heisenbug\",\na common jargon term in software development\n(a Heisenbug is a bug that disappears or alters its behavior\nwhen one attempts to probe or isolate it).\nAt least a note would've been appropriate.\n\n\nThe back cover includes a number of endorsements, including one from\nsomebody named Rob Malda.\nBut don't worry, the book's good anyway :-).\n\n\nIt's important to note that this is a book on debugging fundamentals, and\ndifferent than most other books related to debugging.\nThere are many other books on debugging, such as\nRichard Stallman et al's\nDebugging with GDB: The GNU Source-Level Debugger.\nBut these other texts usually\nconcentrate primarily on a specific technology and/or\non explaining tool commands, not on timeless debugging principles.\nA few (like Norman Matloff's\n\nGuide to Faster, Less Frustrating Debugging)\nhave a few general suggestions about debugging, but are\nnothing like Agans' book.\nThere are many books on testing, like\nBoris Beizer's Software Testing Techniques, but they\ntend to emphasize how to create tests to detect bugs, and\nless on how to fix a bug once it's been detected.\nOf course, once you find a bug, you should add a test for that bug\nin your regression test suite, but testing (including regression testing)\nis outside the scope of Agans' book.\nAgans' book concentrates on the big picture for debugging;\nthese other books are complementary to it.\n\n\nDebugging has an accompanying website at\nhttp://www.debuggingrules.com,\nwhere you can find various little extras and links to related information.\nIn particular, the website has an amusing poster of the nine rules\nyou can download and print.\n\n\nNo book's perfect, so here are my gripes and wishes:\n\n\nThe sub-rules are really important for understanding the rules, but\nthere's no \"master list\" in the book or website that shows all the\nrules and sub-rules on one page. The end of the chapter about\na given rule summarizes the sub-rules for that one rule, but \nit'd sure be easier to have them all in one place.\nSo, print out the list of sub-rules above after you've read the book.\n\nThe book left me wishing for more detailed suggestions about specific\ncommon technology.\nThis is probably unfair, since the author is trying to\ngive timeless advice rather than a \"how to use tool X\" tutorial.\nBut it'd be very useful to give\ngood general advice, specific suggestions, and examples of what approaches\nto take for common types of tools\n(like symbolic debuggers, digital logic probes, etc.), specific\nwidely-used tools (like ddd on gdb), and common problems.\nEven after the specific tools are gone, such advice can help you use\nlater ones.\nA little of this is hinted at in the \"know your tools\" section, but\nI'd like to have seen much more of it.\nVendors often crow about what their tools can do, but rarely\nexplain their weaknesses or how to apply them in a broader context.\n\nThere's probably a need for another book that takes the same rules,\nbut broadens them to solving arbitrary problems.\nFrankly, the rules apply to many situations beyond computing, but the\nwar stories are far too technical for the non-computer person to\nunderstand.\n\n\n\nBut as you can tell, I think this is a great book.\nIn some sense, what it says is \"obvious,\" but it's only obvious\nas all fundamentals are obvious.\nMany sports teams know the fundamentals, but fail to consistently\napply them - and fail because of it.\nNovices need to learn the fundamentals, and pros need occasional\nreminders of them; this book is a good way to learn or be reminded of them.\nGet this book.\n\n\n\nSlashdot\nposted\n\nan earlier version of this review\non February 24, 2004.\n\n\nDavid A. Wheeler is\nan expert on\ndeveloping secure\nprograms and\nquantitative\nanalysis of open source software / Free Software.\nHe lives in Northern Virginia." ], "output": "readability/", "pwd": "/data/archive/1736784779.670267", "schema": "ArchiveResult", "start_ts": "2025-01-13T16:13:22.265418+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "/usr/bin/curl", "--silent", "--location", "--compressed", "--proxy", "socks5://tor-socks-proxy:9150", "--max-time", "60", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 ArchiveBox/{VERSION} (+https://github.com/ArchiveBox/ArchiveBox/)", "https://dwheeler.com/essays/debugging-agans.html" ], "cmd_version": "8.10.1", "end_ts": "2025-01-13T16:13:21.217953+00:00", "index_texts": null, "output": "David A. Wheeler's Review of \"Debugging\" by David J. Agans", "pwd": "/data/archive/1736784779.670267", "schema": "ArchiveResult", "start_ts": "2025-01-13T16:13:21.190873+00:00", "status": "succeeded" } ], "wget": [] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": "https://web.archive.org/web/20250113154249/https://dwheeler.com/essays/debugging-agans.html", "dom": "output.html", "favicon": "favicon.ico", "git": null, "media": "media/", "pdf": null, "screenshot": null, "singlefile": null, "title": "David A. Wheeler's Review of \"Debugging\" by David J. Agans", "warc": null, "wget": null }, "link_dir": "/data/archive/1736784779.670267", "newest_archive_date": "2025-01-13T16:13:42.308273+00:00", "num_failures": 0, "num_outputs": 9, "oldest_archive_date": "2025-01-13T16:13:06.193347+00:00", "path": "/essays/debugging-agans.html", "schema": "Link", "scheme": "https", "snapshot_abid": "snp_01JHG716FN114836390107SFXB", "snapshot_id": "2430513b-f3b6-4062-9990-de40007cbfab", "sources": [ "/data/sources/1736784778-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1736784779.670267", "title": "David A. Wheeler's Review of \"Debugging\" by David J. Agans", "url": "https://dwheeler.com/essays/debugging-agans.html" }