A read an interesting article in Wired a few weeks ago (I get the print edition, but you can read it here.) I thought it was relevant to Distance Debugging because of the comparison of the traditional approach to map-making versus that of the up-and-comer. Basically, it boils down to driving all the roads to see what's going on, versus collecting huge amounts of data such as instant email alerts regarding road changes, scouring local media for information, and looking at satellite imagery to try to infer road status (speed, construction, one-way, etc) without ever leaving the office.

This new approach has started to gain significant ground despite being used by a smaller player. The problem with the "close" approach is that it is about exhaustion, where the drivers are going out and directly observing the state of roads and feeding that into their model. The "distance" approach relies on the fact that people local to the changes will be noting them anyway, and so there is no need to drive roads over and over again.

This is analogous to Distance Debugging versus a close approach such as running the program in a debugger. The debugger is like driving the roads: as you go along you will eventually come along to something worth noting, but will spend a lot of time looking at things you already knew. In the distance approach, you determine what information seems relevant and collect it directly, or have the system dump out information at certain key points. In my experience, and as has been illustrated by the growing market share of Tele Atlas, the distance approach can be more effective and less costly than "driving the roads" since you spend so much less time filtering out redundant data. It will be interesting to see if this trend will spread to other industries.