Having the right "tude"

On October 30, 2006, in news, by

I'm not proud.  And I'll be the first to admit I didn't have the right 'tude' for dealing with a support incident the other night.

I didn't have the right 'tude' the other night.  I called into my ISP support line and didn't have the right "tude" for the first line tech support…and too many us forget that it's the first line that gather the info needed for the second tier.  And sometimes we think that we should immediately get esclated up the ladder when sometimes there's some basics that need to be established.  And then there are times that WE don't see the fact that at an appropriate time an escalation needs to be made… but the key element is AT THE APPROPRIATE TIME.   In my case when the support engineer asked me for the model of the DSL modem, I questioned why they needed the information…but you see they needed to establish baseline information before I was sent to the second tier. 

I was thinking again about this post and about this wiki entry and I'm not convinced that the issue is all in that source code isn't available or that the support engineer doesn't have access to the source code and all that.  I think "oh but if we/they had access to the source code" is a cop out.  I truly do.  Show me a break/fix engineer and he doesn't write code.  That isn't what they need to determine what's going on under the hood.  If a SBS engineer was shipped to a deserted island and given the choice between source code and the entire library of the Sysinternals.com stuff.. I'll bet you a million bucks he or she would take the sysinternals stuff.  Look at me… I can't read code worth a darn.  The last time I coded ANYTHING up was a Cobol and Basic class in college… but now that Peter showed how to do a BSOD analysis?  Man I can't wait until a machine blue screens on me (okay I'm weird..but it's fun).

Reading code is just that… code.  Wanna see some?  Go over to metasploit or milw0rm …okay that's code right?  Exploit code.  Okay …and?  So there's source code for ya right?  Mean anything other than  bunch of stuff to someone who isn't trained to understand what it's doing?  I'm just not convinced that the right place for what seems to me to be a coding issue was a phone call to a department used by folks like me.  Break/fix stuff and all that.  Not to mention IMAP is just a corner case and I don't see it much in SBSland.  I think perhaps somewhere along the line the right "tude" should have been reached and instead of going up the PSS/Break fix… perhaps trying a more coding Exchange newsgroup would have been wiser?  Escalation to a different division?  And maybe asking for a consult with the Support Supervisor?  I don't know…but I do know that …. at least in my opinion… having access to the source code wouldn't give you any better understanding here.

Code doesn't equate to understanding and implementation out here where it counts… ya know?

So next time … including myself.. when you call into support…can you promise me that you have the right "tude".. google first….put in your "exact" error message in the search box.  You may be surprised that someone else had your same problem and someone else has helped them find the answer.  Try out http://www.eventid.net for event errors (buy a subscription to that site in fact) 

But remember: 

There are no dumb questions.  If you think it's a dumb question, it's just dumb because you can't find the answer.  Always ask, as someone else probably has the same question that you have.

For the quickest resolution to your posted issues, please remember the following:

1. Include the following details about the Computer exhibiting the Problem:

    Version installed:

    Service Packs Applied:

    Affected application version and Service Pack:

    Other applications on the box:

    Antivirus Software / Version:



    Hotfixes Installed

2. Details about **other** Computers, for example a client machine, if applicable

    Operating System and Service Pack:


    Antivirus Software / Version:

3. Details about the Network, if applicable:

    Internet Connection Type:

    Number of NICs in the server:


    Network Topology particulars:

4. Details about the issue:

    Full, complete error message wording or screenshot:

    When did the issue first occur?

    What changes were made around that time?

    Steps to reproduce if any:

    Any Additional Information you think would be helpful

* * The fastest resolution is a targeted diagnosis of possible causes. * *  

So be patient… and have the right 'tude' ….okay?


One Response to Having the right "tude"

  1. Tim Long says:

    I mostly agree that source code is not all that useful under most support circumstances. As a software developer, there have been times when I have had problems with third party components that I wished I knew exactly what was going on in the other party’s code. Mainly, that has been because the old VB6 runtime is rather poor in the way it handles and reports errors. If the error is in a closed source component, it can be really hard to figure out what is going on when the error message doesn’t really tell you enough information. However, the situations when I’ve wanted code access have been rare and specific and I’ve been able to resolve my issues through opening a relationship with the vendor of the components.

    There would be absolutely no point in me having the source code for Exchange Server, for example. Even as a seasoned software developer, it would take so long to find the bit of code, understand it and so on, that it wouldn;t be worth the effort. The thing is to have good documentation particularly about interfaces and protocols. Provided the interfaces are documented, then software can be treated as a “black box”. We don’t know what’s inside but we know what goes in and what is supposed to come out. That’s enough for the majority of troubleshooting situations.

    There is another problem with source code access too. People tend to make quick and dirty hacks to fix a particular problem. Different hacked versions of code get circulated and proliferated and it can really muddy the waters to have lots of different versions in circulation. Not that this would necessarily happen with licensed software, but I’ve seen several software authors make their code available then withdraw it because of the increased support burden of unofficial versions being proliferated. You’ll remember that I was guilt of that a few weeks ago with Jim Harrison’s ISA script and that’s why I totally understood when he said “That’s not our code, we don’t support it”.