I was recently introduced to this Brit TV show when someone emailed me a link to the “You can break the internet” YouTube clip. I love it! Now I’ve been watching season 3 online and really would like to see more. We do get BBC America now, but that apparently isn’t who broadcasts it. 
It seems to me that “remote control” technical support (using some version of Citrix or similar technology) is making computer support even worse than it was before. I have now been on the receiving end of remote support 3 times in as many months and I am quite unhappy with it. Without fail, technicians using remote support have wasted a lot of my time and not in a single case did they actually solve the problem.
During the same time period of time, I spoke to 2 support technicians via chat or telephone without them logging on to my system. They actually listened to my explanation of the problems and solved them, both in a brief amount of time.
It just seems like remote control gives bad support technicians an excuse to waste a lot of time poking around on a PC, hoping that they will stumble over some really obvious cause for the problem. In all 3 cases where this has happened to me, the techs did not listen very well to my problem description and were falling all over over themselves to try and get access to my PC so they could poke around.
The latest incident was after switching to a new internet service provider (ISP) a few days ago. Outlook was stuck in the Outlook Send/Receive Progress window, with all of my email accounts not showing any progress. To me, this appeared to be a systemic issue affecting all accounts, like the ISP blocking port 25 (Googling this a bit and looking back at my notes from similar issues with other ISPs confirmed my suspicion).
When I called the ISP’s tech support, the first level tech had no clue what I was talking about (this in itself was a big warning sign to me, since this is clearly a very common problem that every ISP tech should be aware of). After I explained the problem, the tech just absolutely wanted to access my PC. No additional questions, no listening to what I was saying, just “let me take a look”. So I indulged him for about 20 minutes, during which he poked around my email account settings and changed the outgoing server settings for my gmail account (the only one I allowed him to look at) to some other account with the explanation that all outgoing email had to go through their servers first (What the #### ?!?). Eventually, after not being able to get that going, he relented and connected my to the next tier tech support person.
The second tier tech, after listening to my problem description said “sounds like we need to unblock port 25 for you” and did just that. About a minute later, my email was working again. Magic!
Now, to be fair, the first level tech was clearly clueless and could have wasted just as much of my time without remotely connecting to my PC. I also understand that many callers to tech support aren’t necessarily computer savvy, but that would have made no any difference in this case in solving the problem (other than that a less experienced customer might have been stuck with a bad solution, like channeling all outgoing emails through this ISP’s servers, or even have their working email settings completely messed up by this tech).
I’m not saying that being able to remotely access a PC is bad; I use this technology myself and I love it. However, it should be used to aid, not substitute for, proper problem solving techniques. Ask relevant questions, analyze the problem and go from there.
Code encapsulation simplifies maintenance. The more abstracted and isolated a routine is from a larger code base, the easier it will be to adjust, test, and if needed, replace later.
This came to mind recently when I wrote a short routine that determines if a mapped drive is a local drive:
[DllImport("mpr.dll")]
static extern uint WNetGetConnection(string lpLocalName, StringBuilder lpRemoteName, ref int lpnLength);
// returns whether the current drive is local
internal static bool IsLocalDrive(String driveName)
{
bool isLocal = true; // assume local until disproved
// strip trailing backslashes from driveName
driveName = driveName.Substring(0, 2);
int length = 256; // to be on safe side
StringBuilder networkShare = new StringBuilder(length);
uint status = WNetGetConnection(driveName, networkShare, ref length);
// does a network share exist for this drive?
if (networkShare.Length != 0)
{
// now networkShare contains a UNC path in format \\MachineName\ShareName
// retrieve the MachineName portion
String shareName = networkShare.ToString();
string[] splitShares = shareName.Split('\\');
// the 3rd array element now contains the machine name
if (Environment.MachineName == splitShares[2])
isLocal = true;
else
isLocal = false;
}
return isLocal;
}
There is a post on stackoverflow asking how to do this, and, like many others, it has several answers showing several ways to do this. So, is my method correct? This code seems to work, but I’ve been programming long enough to know that code that “seems to work” doesn’t necessarily work in every circumstance and could have other negatives, such as performance issues.
So, knowing that this code I may have to tweak or replace at some future point in time, I will try to encapsulate it as much as possible to make it easier to work with in an isolated manner later. By keeping the code in a separate method, I can easily use a unit test to try it in various test scenarios without affecting any other code.
Of course, this is a very simple scenario, which made it perfect for this post. It can be much tougher to abstract and isolate more complex code, but that doesn’t mean we shouldn’t strive to do so whenever possible.