• anonymous (unregistered)

    A good example of Heisenbug, when you try to observe the bug (by setting the debug flag), the problem would simply goes away :)

  • Mike5 (unregistered) in reply to Indifferent
    Indifferent:
    Czenda:
    Why didn't he update the ticket with the information he found?

    I was rather wondering that... it really annoys me when I get back to a user to say "we fixed your issue" to be told that hey found the buy days ago and didn't bother to let us know.

    It always strikes me as the other side of the coin from coders who don't release patches when they know there's a bug and have fixed it in source.

    I'm a coder and I agree completely. So, for a bug that takes a few hours (or less) to find, the vendor first asks the customer to perform some needless tasks (like re-installing Java and such) that in the end takes much more than the actual debugging, then does absolutely nothing for weeks, and in the end expects the customer to fix their problem?

    What exactly are they getting payed for here?

  • Rudolf (unregistered)

    Really this is a good reason why software companies should always "eat their own dog food"

  • Dog's breakfast (unregistered) in reply to Canuck

    Or a Canadian using american language. See it all the time now unfortunately

  • Enkidu (unregistered) in reply to JW

    "After pouring over the application code..."

    Maybe he's an open sauce advocate?

  • v (unregistered)

    He got surprisingly detailed code for a decompile... variable names and all. I guess compilation does not mean the same thing in Java as what the rest of the world thinks it means...

  • Anonymous Coward (unregistered)

    There is a word missing: Water. At least I hope it is water he poured over the source code.

  • HerrOttoFlick (unregistered) in reply to guestimate
    guestimate:
    You're a shit businessman.:
    You're the difference between a company that people like to use, and a company that people hate but have no choice but to use. Only one of those types of companies tends to remain successful in the long run.
    Tell me, what mechanism do you have/does your company in place for financially dealing with people who do such bugfixing for you ?

    You know, reembursing them for the time, energy and money they spend on finding a solution you/your company was incapable of finding (read TFS), as well as the loss of time/money because of your product not doing its work.

    You have not even considered it ? Than you are the kind of person (businesman?) I do not really want to deal with.

    Financial transactions are a two-way street. If you expect to be payed for your efforts than you should damn well expect to pay others for theirs.

    They have already been paid you chuffing moron - that's the premise of third party software components, you give them money, they give you black box software that works.

    However, it is much more common that you give them money, they give you bug ridden bits of shite that barely work and that they can't tell you why it doesn't work.

  • Actually (unregistered) in reply to JW
    JW:
    "After pouring over the application code..."

    The correct word there is "poring". Attention to detail matters in English just as much as in code...

    (Based on precedent, at least one person is going to tell me I'm wrong, after doing no research whatsoever. Don't be that guy.)

    Actually it doesn't. See, most (all?) compilers, upon seeing that error (substituting a similar-looking valid token for the intended one) would not function correctly. They would either barf because "pouring" or they would parse it as meaning that a liquid was distributed over the code in some fashion.

    A human reading English, on the other hand, very quickly figures out that the intended token was "poring" or, at any rate, the intended semantics were that they reviewed the code carefully.

    So yeah, there's no "research" required -- it's a basic fact that human beings reading English are capable of contextual error correction when a substitution of a similar looking/sounding token is made but the resulting sentence would make no semantic sense.

  • Actually (unregistered) in reply to Mike5
    Mike5:
    Indifferent:
    Czenda:
    Why didn't he update the ticket with the information he found?

    I was rather wondering that... it really annoys me when I get back to a user to say "we fixed your issue" to be told that hey found the buy days ago and didn't bother to let us know.

    It always strikes me as the other side of the coin from coders who don't release patches when they know there's a bug and have fixed it in source.

    I'm a coder and I agree completely. So, for a bug that takes a few hours (or less) to find, the vendor first asks the customer to perform some needless tasks (like re-installing Java and such) that in the end takes much more than the actual debugging, then does absolutely nothing for weeks, and in the end expects the customer to fix their problem?

    What exactly are they getting payed for here?

    Usually we spin up the debugging process on the initial report. It improves the metrics since the response time is usually calculated from when we declare that the report has sufficient information to be actionable until we resolve it.

    Captcha: saepius -- it's very saepius to lower your response times by a day in this fashion.

  • Norman Diamond (unregistered) in reply to Actually
    Actually:
    JW:
    The correct word there is "poring". Attention to detail matters in English just as much as in code...
    Actually it doesn't. See, most (all?) compilers, upon seeing that error (substituting a similar-looking valid token for the intended one) would not function correctly. They would either barf because "pouring" or they would parse it as meaning that a liquid was distributed over the code in some fashion.
    In some languages, misspelling an identifier automatically gives you another perfectly valid identifier.

    Like the VB6 program that assigned FLASE to a variable and it worked perfectly, because guess what the default value was for that newly created variable, and guess how that default value was converted when a Boolean was needed.

  • (cs) in reply to You're a shit businessman.
    You're a shit businessman.:
    You're the difference between a company that people like to use, and a company that people hate but have no choice but to use. Only one of those types of companies tends to remain successful in the long run.
    Absolutely true. Although I still don't understand why only companies that people hate but have no choice but to use, remain successful in the long run.
  • (cs) in reply to nerd4sale
    nerd4sale:
    You're a shit businessman.:
    You're the difference between a company that people like to use, and a company that people hate but have no choice but to use. Only one of those types of companies tends to remain successful in the long run.
    Absolutely true. Although I still don't understand why only companies that people hate but have no choice but to use, remain successful in the long run.

    Simple. The former type of company gets bought out by someone who just wants to make a quick buck without knowing what they're doing. At best, they turn it into the latter type of company, but more often run it into the ground. Companies that people hate are not seen as being as attractive to the idiots who do that crap, and may not even be available to them to do so.

  • (cs) in reply to Anon
    Anon:
    You missed the point.

    The point is that if I am paying YOU for YOUR supposed "Expertise," then YOU need to learn how to do YOUR FUCKING JOB properly.

    It isn't the CUSTOMER'S responsibility to fix YOUR FUCKING PROBLEMS unless they explicitly signed on for that kind of testing.

    This wasn't an issue on the customer's side, and the customer shouldn't have needed to spend ANY time debugging the vendor's code. The ENTIRE FUCKING POINT of using third-party code is to avoid paying to build, debug, and maintain your own solution. If we're building, debugging, and maintaining the third-party solution, WHY THE FUCK ARE WE PAYING YOU?

    If you're more concerned about not doing someone else's job than you are getting the software you used fixed, there's no real problem with your attitude. Sure, you're taking decades off your expected lifespan, but the rest of us sure aren't going to complain about that.

    But, for me, I like to have my software work. If that means I need to give the vendor a bit more information than I'm supposed to be able to get, that's fine by me, so long as I don't risk jail time. Actually decompiling the vendor's proprietary code can risk jail time, depending on your jurisdiction and the governing law on your software license.

    I've had vendors do a double take, when I tell them that the bug is in <buggy subroutine name>, between lines <start> and <end>. I had one start to threaten legal action against my company until I pointed out how I got the information - and suggested that their techs were incompetent for not doing the same thing to track down the issue, as they'd purportedly been able to reproduce the problem intermittently, but hadn't managed to isolate it, so they couldn't fix it. I didn't actually say incompetent, but I came close enough that at least one tech from the vendor realized what I was saying.

Leave a comment on “Caching Debugs”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article