Why do IT professionals always blame eachother

thescouselander

vyle wrote: »

Not entirely to do with the main thread, but im currently using the android app with no issue with my ST50 on my galaxy S2.... what version of the viera remote are you using, for what tv, and what handset? I trust you're not running it in demo mode are you?

Yes, I know the app works on some phones but not others. The TV is a G30 and my old Desire HD will connect ok but the app wont work on my Razr I. It seems from the reviews loads of people are having similar problems with various phones.

I had a quick look with Wireshark and its pretty clear the app just doesn't send any network traffic at all from the Razr I - what should happen is a broadcast message should be sent to the network in order to find TVs that are present but nothing happens. Its probably just some issue with how the app is put together causing issues with certain builds of Android but I'd expect better from a company as big as Panasonic.

tgon

Same reason a plumber never looks at a previous repair and says what a good job it was.

fluffnutter

thescouselander wrote: »

I've had a couple of problems recently where various bits of IT aren't quite compatible with each other. Why is it though, when you try to get someone to fix the issue, IT support staff will always blame the other system.

For example, at work we have difficulties emailing another organisation because of a compatibility issue between the email systems. IT support on either side are blaming each other because the other system "isn't implemented properly".

Now as a Systems Engineer I am familiar with the problems of getting things to work with each other and the inevitable differences in interpretation regarding standards etc.

Where I work we accept there is a compatibility issue and go about fixing it. By contrast, in the world of IT, it's always the other guys fault. What is it about the IT profession that means they must always pass the buck instead of helping the customer out? It just ends up in rubbish service for the customer.

Systems engineers are part of the IT industry.

prowla

It was probably implemented on the cheap, without anybody being responsible for planning & designing the solution, specifying the interfaces, thinking through the integration, etc.

Unfortunately doing things properly is expensive.

cherrub

Esqui wrote: »

Almost certainly because they have no idea why it doesn't work

I think this is almost always the case. I have more than once threatened to lock opposing vendors in a meeting room and give each of them a half brick and let them fight it out. Loser's company have to fix the issue. This has often seems as good a way as any other other of just getting somebody to take responsibility and fix the d*mn issue

thescouselander

fluffnutter wrote: »

Systems engineers are part of the IT industry.

Yes, that's true but systems engineers also work in other fields (as in my case). I guess my complaint is more with the people who work on support desks.

prowla

thescouselander wrote: »

Yes, that's true but systems engineers also work in other fields (as in my case). I guess my complaint is more with the people who work on support desks.

Usually the people on the support desks jobs is to support running systems rather than do the project work/changes.

mattyprice4004

I would apologise but it's my colleagues fault

vyle

To actually reply to the thread, I had a think, and it's probably because whoever is dealing with the issue doesn't know what the previous guys did, and in the case of software, won't have an intimate knowledge of what the source code contains, so sorting out a problem will involve a lot of guessing.

If you ring up a support desk saying there's a problem with X software interacting with Y, and X is the company's own software, they'll think: "Well we tested the software under these circumstances and it was fine. We've never tested Y. We don't know Y. Y is the problem." because that's sadly how support roles work. You can't know everything, so have to narrow down what the problem is most likely to be given the information, and act on it.

The same with the panasonic app really. They'll have tested it on key handsets, and then turned it loose. They know that under the right circumstances, it works fine, based on their pre-release testing. If it therefore doesn't work, because it's on a handset they've not acounted for, then it's being used under the "wrong circumstances" as far as their support is concerned.

thescouselander

vyle wrote: »

To actually reply to the thread, I had a think, and it's probably because whoever is dealing with the issue doesn't know what the previous guys did, and in the case of software, won't have an intimate knowledge of what the source code contains, so sorting out a problem will involve a lot of guessing.

If you ring up a support desk saying there's a problem with X software interacting with Y, and X is the company's own software, they'll think: "Well we tested the software under these circumstances and it was fine. We've never tested Y. We don't know Y. Y is the problem." because that's sadly how support roles work. You can't know everything, so have to narrow down what the problem is most likely to be given the information, and act on it.

The same with the panasonic app really. They'll have tested it on key handsets, and then turned it loose. They know that under the right circumstances, it works fine, based on their pre-release testing. If it therefore doesn't work, because it's on a handset they've not acounted for, then it's being used under the "wrong circumstances" as far as their support is concerned.

Yes, you could be right here. And that being the case it would probably be better (in the case of the Panasonic app at least) to declare the configuration in question is not supported rather than giving the customer the run around by blaming everyone else they can think of.