Physical Distance, while somewhat self-explanatory, can be used to describe both an issue with physical proximity, and also with access. There are servers many miles away on which I have shell access and can therefore directly observe and query the system. There are also servers that run my code that I am several steps removed from and into which I have no direct visibility. Physical Distance is a problem because it means that manipulating the system requires some local intermediary. All of your data collection and actions are then filtered through them, and their oversights and mistakes can derail the most careful debugging process.

Physical Distance also acts as a complicating or driving factor in the other kinds of distance. In yesterday's post I mentioned the unobserved changing of hardware or software as a kind of mental distance. However, with physical access, even if you aren't notified of the change directly, once you note its possibility, it is trivial to rule in or out. Without it, you have to rely on your intermediary to attempt to verify, and they may not always be correct. Physical Distance can also be a big factor in Social Distance (more on this tomorrow) since it can be hard to gain user trust without being in physical proximity, and Temporal Distance (Monday), since problems can go unreported if you are not around to observe them.

The keys to overcoming physical distance include techniques such as developing systems that provide multiple, mutually supporting data points to help root out errors made by the intermediary, and identifying and cultivating relationships with high-quality intermediaries. More on this in the discussion about tools and techniques.

Tomorrow: Social Distance