f l u e n c y f u m b l e

I used to be a newspaper editor.  As such, I was Responsible — with a capital R — at the end of production to ensure that the PDF’d file containing the day’s work, tomorrow’s newspaper, made it to the presses error-free.  It was during this time that I witnessed a great phenomenon: infallibly, one hour before deadline, everything goes wrong.  The server crashes, the printer backs up, computers forget how to create PDF files, QuarkXPress switches into Spanish-language mode.  Let me share my usual troubleshooting techniques:

— Resetting computers: the magic cure

— Sighing heavily

— Unplugging the printer, then plugging it back in and hoping for the best

— Drowning my sorrows in a Diet Coke from the vending machine

As the reader might imagine, frustration and giving up often ensued.  Snyder’s section on debugging, Chapter 7, offers the antidote: logic.  The author outlines a series of steps (replicating the error, identifying the specific problem, eliminating “obvious” causes, dividing the process, and reassessment) that seem intuitive — but often aren’t, in the heat of deadline.

I’ve found what usually happens in the face of a technical problem that must be solved quickly is blame … on a user, not a cause.   Snyder points out that this isn’t all wrong: “When a computer is in an error state despite our thinking that everything should have worked out perfectly, two of the three possible problems — wrong data, wrong command or wrong system — involve us.”  We users are usually guilty, especially when under the kind of stress imposed by a pressing deadline, of getting hasty — hitting buttons and clicking rapidly around until a problem solves itself.  It happens all too often that this complicates a problem, opening up unwanted applications and sending conflicting commands to a system already suffering from some kind of error.

However, slamming buttons or blaming a peer are solutions hardly as practical as Snyder’s systematic diagnosis steps.

And for those of us who are too frustrated to even think logically through Snyder’s steps, good news — programmers offer various kinds of automatic or algorithmic debugging.  This site is a collection of links to programs designed to make the troubleshooting process simpler.  It includes, among other things, model checking, a Carnegie Mellon project for “formally verifying finite-state concurrent systems,” real-time software checking information and a variety of digital bibliographies on the subject.