• Miauen (unregistered) in reply to Mikey
    Mikey:
    [[My response would be: I checked it out, weird things are not happening, problem solved. And then proceed to do nothing until a better bug description was forthcoming or I was fired.]]

    Amen.

    With my luck in these cases I'd open a dialog directly with the head of QA and get a definition of "weird." I'd fix it, have the bug closed and verified, and then have some other random yahoo come along and reopen the bug for another set of "weird" behaviors that have nothing to do with the first set.

  • anonymous guy (unregistered) in reply to Bill
    Bill:
    anonymous guy:
    Arrastia:
    That happened to me many, many times when I worked for a company which provided software maintenance&management for an insurance company (read: fixing bugs and tweaking their software to support their changing business model on a daily basis).

    [snip...]

    End of the day, if I am paid to track down a problem with a poor description and which probably is nonexistant in the first place, then I will probably do it. Who knows, sometimes the costumer is right and I actually find something to fix.

    No, that's an entirely different situation. You were being paid to track down the problems of end users who can not reasonably be expected to know what a good bug report is. Your job involves a lot of people skills and coaxing information out of non-computer people. In that situation, it's perfectly reasonable to chase down false leads and do what you did.

    Having a QA dept which can reproduce the problem, but won't even let you into the room to see them doing it is not reasonable.

    Go back and re-read the OP. There is ZERO evidence that it was a QA dept. All he said was UAT and testers - that could very likely mean end-users tasked with testing the app before rollout.

    You're right, I misread that. However, everything else points to it being a much different situation. Regular office workers in the server room? That they wouldn't let anybody into? And, as you say, it hadn't been deployed yet. Though I guess its not all that dissimilar, still you say "No, none was able to reproduce the error in a test environment" vs. what is explicitly a testing environment. I guess it takes all kinds, if you want to spend your time on the phone hand-holding people who aren't coherent enough to tell you what their actual problem is, and then lie about how they used the program, then more power to you! Businesses do need that job done sometimes. I'm a programmer because I enjoy programming, not dealing with liars and office politics.

  • VARCHAR3 (unregistered) in reply to doug
    doug:
    Hate to be the spoil sport but, maybe the fan is only magnifying a problem that is still not fixed. The inability to handle an exception when the network connection is down.

    Yeh, you work on that. Once you have that "exceptional" code written, send me copy. I really need my users to be able to keep working on the network, even when it's down!

    Thanks -

    [email protected] (MircOrsqle Server 2005 10g SP3a)

    CAPTCHA: gygax (looks like the captcha is now fixed)

  • Bill (unregistered) in reply to anonymous guy

    [quote user="anonymous guy]You're right, I misread that. However, everything else points to it being a much different situation. Regular office workers in the server room? That they wouldn't let anybody into? And, as you say, it hadn't been deployed yet. Though I guess its not all that dissimilar, still you say "No, none was able to reproduce the error in a test environment" vs. what is explicitly a testing environment. I guess it takes all kinds, if you want to spend your time on the phone hand-holding people who aren't coherent enough to tell you what their actual problem is, and then lie about how they used the program, then more power to you! Businesses do need that job done sometimes. I'm a programmer because I enjoy programming, not dealing with liars and office politics.[/quote]

    I'm basing a lot of my opinion on the picture of the server room originally posted. it literally screamed "small company" not "large corporation".

    As for the other stuff, I actually take pride in being able to bridge the communication gap between end users who are usually trying to provide information (albeit in a very "Cargo-cult" way) and developers who cant' stomach getting their hands dirty dealing with users (you know, the whole reason why we get paid to write this stuff!!).

    For me, it's not about "programming", it's about "solutions delivery".

    PS: I would have posted sooner, but my Captcha was "onomatopoeia" and it took a while.

  • Kuba (unregistered) in reply to Iceman
    Iceman:
    olsner:
    The application should have been built from the start to gracefully handle temporary disconnections...

    That's all very well, but if it is a browser based application, the browser is going to return a server error when the server gets disconnected from the network, since the connection between the browser and server has been broken.

    Thank $DEITY, most everyday browsers don't monitor the LINK status of individual network interfaces. Because that's the only what you say would happen. Indirectly this would happen if the OS in question would reset the routing tables as soon as the link was down, which would possibly also reset the connections. I tried it on a bunch of PCs around here, both FC6 and XP machines, and they are completely oblivious to turning ports on and off at the network switch. Heck, even the two servers didn't mind killing their ports at the switch for 5-10 second stretches. All that in a busy 15-person office.

    TCP/IP connections are fairly resilient when it comes to packet loss, so a mere loss of ethernet link should not immediately kill the TCP/IP connection. It won't time out in 3 seconds. Or so one hopes.

  • Kuba (unregistered) in reply to Mike5
    Mike5:
    That's just stupid. It's obvious that he should have used a connectionless protocol. And now he's trying to blame the poor tech for his incompetence.

    Nope. The infranstructure on the server should have been configured such that network interfaces are kept up in spite of link failures. I.e. if the link is down, the interface is a bit bucket, but it exists. Thusly, the TCP/IP connections are simply waiting for things to happen, but they don't reset. TPC/IP would then gracefully handle a network cable disconnected for a few seconds. The stack could be configured to even handle minute-long disconnects, with only the application being "stuck", but recoverable. Sheesh, that's so basic.

  • (cs) in reply to Paul
    Paul:
    I guess this guy's modules were the only ones on that server that access any network resources. That, or all the other modules silently swept their exceptions under the rug.
    I wouldn't be surprised. Recently I took over a webapp that swallowed ALL exceptions and did NO logging. A server error such as a db connection failure would result in a valid response, just with no relevant data.

    When I added exception handling and logging, I started getting questions about wtf I was doing to break the application since QA were getting error messages and stack traces in the logs when some backend modules were down. Luckily I'm not a junior engineer and have a good enough reputation to be listened to when I pointed out we need enough information when something goes wrong so we can FIX problems instead of ignore them.

    Captcha: howdy

    So, maybe there are lessons to be learned from this:

    1.) If you are stuck with a no-clue and/or indifferent customer and a contractor/ consultant, then it is good for you to swallow all exceptions and do no logging: No muss, No fuss. Define "no-clue and/indifferent customer": A customer which is interested in the mechanics of the thing and/or with whom it is politic to avoid error messages (becuase they are bean-counters and/or in order to get your invoice paid).

    2.) Implement error logging anyway and enable/disable with a runtime- or compile-flag so if the brown stuff catches up with you, then you have better investigative means already in place.

    Cynical, isn't it !?!

  • (cs) in reply to Crookeddy
    Crookeddy:
    anonymous:
    Crookeddy:
    Ours submitter anonymity (he we will call "from part of Steve") felt this puncture, therefore. It would methodically develop accurately and a module that has admirably worked in atmospheres of the development and the test of the bank, but has pronounced UAT. That that is probadores had uncovered a bug in the module that they could not reproduce. The official description was that the module has rendered "disowned things" to arrive.

    If the way this post was written isn't a joke, then I'd say it's a wtf in and of itself.

    Why it is that is wtf ay? I do not include, when you come and you examine the individuals in my country, my language you speak one I keep excessively condecending the observations the himself.

    Honestly, dude, I understand every word you say but your meaning escapes me completely. And that is not because because of me.

    Sorry, dude, these are the plain harsh facts: you appear to use english expressing yourself in your native language. Listen to the BBC or read Shakespeare or Tom Clancy or something.

  • (cs) in reply to icelava
    icelava:
    lackluster:
    Is there any sort of professionalism left in this world?
    Of course there isn't any. The world is alot more uglier than you think.

    There never wasn't any. Either your mind is switched on or off when you do what you are doing ... that is all that there is to it.

    Procedures, regulations, checklists: all are balderdash. A dud with a checklist is still a dud. If he does something right then he is just lucky. If you have trouble believing this then look at any government clerk ....

  • (cs) in reply to jayh
    jayh:
    I remember a case where a home user claimed the computer would trash when the dog barked. The skeptical tech eventually went to the house, and nothing seemed wrong till they put the cat out. After a flurry of barking, the computer reset.

    Apparently the dog's 'invisible fence' was plugged into the same outlet as the computer.

    "Invisible fence" ?

  • (cs) in reply to Kuba
    Kuba:
    Iceman:
    olsner:
    The application should have been built from the start to gracefully handle temporary disconnections...

    That's all very well, but if it is a browser based application, the browser is going to return a server error when the server gets disconnected from the network, since the connection between the browser and server has been broken.

    Thank $DEITY, most everyday browsers don't monitor the LINK status of individual network interfaces. Because that's the only what you say would happen. Indirectly this would happen if the OS in question would reset the routing tables as soon as the link was down, which would possibly also reset the connections. I tried it on a bunch of PCs around here, both FC6 and XP machines, and they are completely oblivious to turning ports on and off at the network switch. Heck, even the two servers didn't mind killing their ports at the switch for 5-10 second stretches. All that in a busy 15-person office.

    TCP/IP connections are fairly resilient when it comes to packet loss, so a mere loss of ethernet link should not immediately kill the TCP/IP connection. It won't time out in 3 seconds. Or so one hopes.

    Oooooooookaaaaaaaaay: so you were flipping ports at the switch and presumably, left your cables in place. So here is what you did:

    1.) Assuming you have your normal standard switch then the network adapter would still report a connection on the most basic hardware level since most switches/hubs still maintain the electrical conditions on the most basic hardware level even if the port at the switch/hubs has been deactivated on a higher ISO level. 2.) You deactivated the port(s) in question, waited some time (presumably from a few seconds to a few minutes) and activated them again. The intermitting time period is an eternity to a computer.

    Now let us look at the situation described in the post:

    3.) A faulty network cable with an intermittent loose contact.

    4.) A swiveling fan (which is vibrating - don't tell me it is not - all swiveling vibrate: the bigger they are, the more they do it) touching the network cable in question when reaching one end of its swiveling track.

    This results in two really two importants facts:

    5.) Every time the fan disturbs the faulty network cable, the connection is dropped on the most basic hardware level which results in the network adapter in the server reporting to the network "no cable" connection which results in all kinds of actions being performed in the OS like releasing of DHCP IP addresses .... and so on. And vice versa when the connection is re-established again when the fan stops disturbing the cable.

    6.) Chances are, since the fan is vibrating that you do not have a comparatively clean scenario like: the fan starts disturbing the cable, connection drops, the fan swivels back and forth to and from the end of its motion range (seconds pass ...), the fan stops disturbing the cable, connection is reestablished. No: what you have is like this: the fan disturbs the cable while swiveling and connections are dropped and restablished (as described in (5)) to the tune of several time a seconds due to the vibrations of the fan. And that is a completely different kind of animal, my friend. No OS I know of is written with something with something like that in mind.

    And I did not even start discussing how a scenario as described in (6) ends up being handled by the OS on the server and running the application on both the client and the server. I leave this to your imagination - but you can be sure that no dev is making allowances for such a rare scenario.

  • (cs)

    that sounds slightly familiar to what I had to deal with once: no server room but close :)

    I was in a client's consultants sit here room (a big room with 15-20 consultants) and one day a senior manager steps in the door and bellows "who did it!" Of course we're all "wtf?" and ask what he's talking about. This is a fortune 100 company mind you so he takes the high road and tells us that not one room past ours can get on the network let alone the manufacturing arm can't run lines without their inventory management screens. Well come to find out that the consultants had nothing to do with it...it was the general contractor and their remodel of a series of rooms that had nail-gunned the cables down to insure nothing was loos....including a network cable or two.

  • (cs) in reply to cklam
    cklam:
    jayh:
    I remember a case where a home user claimed the computer would trash when the dog barked. The skeptical tech eventually went to the house, and nothing seemed wrong till they put the cat out. After a flurry of barking, the computer reset.

    Apparently the dog's 'invisible fence' was plugged into the same outlet as the computer.

    "Invisible fence" ?

    Presumably one of the ultrasonic collars, or an electric shock-fence using a contact on the collar.

    I thought the photo of the server room was just a total jest someone completely unrelated to the WTF just posted with a sarcastic comment. Is that not the case?

  • NefariousWheel (unregistered) in reply to Zylon

    My favorite was in a VAX shop in a power company where the computer room was running perilously close to the max power that could be put into the room; just a few watts on one riser, so we put child-proof plastic plugs on the power outlet, taped them over with a card that read "touch this if you like hospital food". When I confronted the cleaner who brought down the state network by plugging his floor polisher into that power outlet, he looked me right in the eye and said "Hey, hospital food isn't that bad. Oh...". I took some side cutters and clipped the end off the lead to his floor polisher and told him to give it to his supervisor, with my complements.

  • luker (unregistered)

    ..."tech" my ass....

Leave a comment on “The Bank Has Spoken!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article