Having started out in tech support and moved up to DBs, I've got quite a bit of experience working with end-users. And the one question I have is, Why is it that they never seem to be able to give you the full story about what's going on?
This is the question I still find myself asking after all these years. And more importantly, there's got to be a word for that. Here's a perfect example, and it's not as much an end-user as much as it is a fellow IT and DB coder. One of my ETL guys came up to me last week and said simply, "I can't open this SSIS package on my box." I said, "OK, what's the error you get?" He told me the error and I started down the path of troubleshooting that error with that package. And sure enough, the package errored out whenever I tried to open it. Because you know, you have to verify these things for yourself.
So I tried the usual fixes and then hit the Internet for some more obscure ones, of which I found three. None of them worked either. I then asked him if he was sure the package was good -- maybe it was corrupt somehow. He said, no because it opens just fine on another box. OK, well that kills that. OK, so what could this be then? He sat there and watched me look at different aspects of that package and even rebuilt a couple of the SQL connections to make sure they weren't corrupt somehow. Nothing worked. No matter what I did, the packaged still gave the error when it was opened.
So I started asking more questions to expand my knowledge of the situation. Have you changed anything on the box? Have any updates been applied, etc.? Right? All's good there. Then I came to the question that turned out to be the key to this whole issue. Do you have this problem with any other packages? The answer may/may not surprise you, right -- the answer was yes. As a matter of fact, I've never been able to open up any package on my box without errors, he said.
OK, so now we're getting somewhere. But I ask you -- why didn't you tell me that originally? You're in IT. You should know the questions to ask and the information to give. You don't think that wasting my time for half a day chasing a problem that doesn't exist is worth preventing? Why wouldn't you come to me and tell me that you've never been able to open up any package? Is there anything else I need to know? No, that's it.
So I go down that road and come to find out that there was something else I needed to know. It's not all SSIS packages he was having troubles with. It was all packages that had a DB connection in them. If he created a new package and only did FTP or OS-level tasks, everything ran just fine. So that again is another issue entirely.
That was just an example of the kind of things users do to us all the time, and it doesn't appear to matter how much experience they have. So what we need is a good word or phrase for that kind of deception. I don't think it's malicious because they do want their problem fixed. But they continually give us only half the story, and sometimes not even that. I've had several programmers come to me with stuff like that. And I've had Windows guys approach me in the same manner as well. So what is it about having a minor problem that makes people lose all sense and just not tell you what you need to know?
OK, so what's the phrase for that kind of deception?