Operational Distance is the gap between you and the power structure that has control over the system you are trying to debug. Sometimes, that gap is essentially zero, as when you are the adminstrator and arbiter of the system. Other times, it is a gulf requiring you to navigate dozens of people on the way to obtaining permission to even view a log file. Operational Distance is often overlooked in the pre-production stages because at that point it doesn't really exist. However, once the system is fielded and users are either reliant on it, or are simply naturally and somewhat rightfully resistant to change, it's too late. Without the right structures and agreements in place beforehand, it can be difficult or impossible to debug a problem because of all the organizational roadblocks in the way, not to mention that even if you fixed it, you wouldn't be allowed near the system to actually install new code for months.

Operational Distance can be overcome with careful design and lots of communication between you and your customer, but you have to be explicit about what you will need to be able to do after the system is deployed.

I have covered the five basic types of distance, Mental, Physical, Social, Temporal and Operational. I would now like to transition to discussion about some general concepts and ideas about debugging that I think are undercovered or underemphasized in the current literature. The first series of posts will relate to common problems that many debuggers (the people, not the software) run in to that are avoidable. The second series of posts will cover some uncommon general techniques and skills that are relevant to a wide variety of debugging situations.

Tomorrow: The Big Two: Confirmation Bias & Implausibility