Reviewed by Alison Chaiken
Recommended.
David Agans’ Debugging is a treatise about professionalism in bug-hunting, a skill which is arguably less susceptible to automation than other software-engineering tasks. The text provides guidance both about specific best practices and the mental habits which accompany them. While the strategies will be most valuable to new graduates, there’s plenty of sage advice which may be familiar to seasoned engineers but which bears repeating. Like The Mythical Man-Month, Debugging is a bit old, but software-project planning and bug-finding have similarly resisted our attempts to improve them.
Agans is an entertaining writer. In each chapter he shares a detailed account of a debugging quest, some of which were admirably clever, and some of which set off resolutely in the wrong direction and never returned. The anecdotes are mostly about errant software and flaky electronics, but also describe investigations of mysterious home and automotive problems. He illustrates Rule 1 ‘Understand the System’, with the observation that, “If you’ve never heard a chain saw, you might think the problem has something to do with that godawful loud buzzing noise.”
The chapter about Rule 2, ‘Make it Fail’, relates how spraying a garden hose on a roof which had an intermittent slow leak accelerated progress. Here Agans wisely points out that, “Simulating the conditions that stimulate the failure is okay. But try to avoid simulating the failure mechanism itself.” Properly simulating the failure mechanism itself would imply understanding the root cause, and it is the rush to identify causes without enough information which is at the heart of painful and protracted bug searches.
The principle of delaying judgement is emphasized in Rule 3, ‘Quit Thinking and Look’; Rule 7, ‘Check the Plug’; and Rule 8, ‘Get a Fresh View’. Rule 3 is addressed to those of us who decided to rewrite a code section about which we feel mildly guilty rather than slog through log files or reread documentation. Don’t do it! Rule 7 reminds us that a bug search which has gone on a long time is undoubtedly based on wrong assumptions. Agans notes, “Your car won’t start. Before you take apart the carburettor, are you out of gas?” Rule 8 advises that ‘rubber ducking’ will fail if the frustrated debugger conveys only his or her wrong theories about the error rather than the simple facts. These chapters reinforce good debugging habits and speak directly to senior engineers who have wasted an embarrassing amount of time uncovering problems which turned out to be simple. Rule 5, ‘Change One Thing at a Time’, and Rule 6, ‘Keep an Audit Trail’, present other well-known but often neglected advice. One valuable suggestion is, if you’ve attempted a fix which did not work, don’t assume it has no effect, but back it out immediately!
The last chapter is specifically aimed at engineers who must respond to customer bug reports. Agans emphasizes the need to ship products with configuration-reporting tools which gather system details with minimal customer input. He advises that building in debugging tools should be part of the design process of all new products, not just those which are shipped to end users. Reporting bugs is, after all, yet another non-coding programming-related skill at which not everyone will excel.
As with articles about ‘8 best dating tips’ or ‘5 trending vacation spots’, Debugging’s discussion of its Rules sometimes feels a bit laboured. Nonetheless, even the most battle-hardened among us may find its reminders helpful. The couple of hours needed to read the text are minimal in comparison to the weeks one can waste investigating an intermittent failure.
Website: https://debuggingrules.com/
