The Social Distance factor is often overlooked when attempting to debug a problem. It takes several forms, but is mostly boils down to a single issue: you are not a member of the same group as the people using the system. You belong to the software developer group, while the people using it belong to the accounting, or medical, or whatever group has contracted your services. You think about the software in a different way and you use different terms, which can make communication about issues difficult. These differences cause an initial distrust that gets reinforced through these communication problems.

Social Distance causes problems in a variety of ways, for instance:

• Bugs are reported in terms of the user experience, not in terms of the programmer understanding. This leads to confusion about what is actually wrong, and worse, the severity of the problem.
• It can be hard to get access to the right people when you are part of the "out" group. You are often not seen as a priority.
• The users' perception of the job you are doing can vary significantly from your own. You may believe that they see you as delivering key functionality in a timely fashion and fixing problems rapidly, while they actually see trivial updates and constant breakdowns.
• It is often difficult to know who to trust when receiving conflicting information from different people within a customer. Being on the outside, you won't know useful information like, "So-and-so always has a million complaints about everything, just ignore him/her", or "If So-and-so says fix it, you better fix it".

Social Distance is the main reason we hate technical support and the applications we use. When things go wrong or don't work as anticipated, we feel that either the authors don't understand our problems, or they don't care. It also tends to feedback quickly, so that once you are perceived by users to be an asset, your subsequent actions will be seen as good, and if you are perceived as a problem, your actions will be seen as detrimental or annoying.

Overcoming social distance and getting to be "one of the team" can go a very long way towards solving debugging problems. You will get better information, get reports more quickly, and will be given more opportunities to get things right. The keys to doing this include practicing good information hygiene, managing your reputation, and like with physical distance, identifying and cultivating relationships with high-quality intermediaries, but then additionally using them to help gain the trust of others.

Tomorrow: Temporal Distance