• BruteForce (unregistered)

    Wow.

    Btw alex, did you get an oracle to feed your captcha the words?
    Mine says bedtime, and thats sure something that should apply to that vendor after say, 20:00?

  • KattMan (unregistered)

    ok So I'm confused, did they fail to succeed or succeed to fail, and by doing so did they succeed where others fail.  If it "worked properly" in QA does this mean they were getting the right results, or not getting any results which was expected.

     This one just makes my head hurt.

  • (cs)

    Nice, another one to add to the list from yesterday.

    War is peace.

    Freedom is slavery.

    Bugs are features.

    Failures are sucessess.

    <!-- End: CommunityServer.Discussions.Controls.PostDisplay.TextPost -->
  • (cs)

    There are no errors as long as I don't know about them.

  • anon (unregistered) in reply to tmountjr

    I've known some programmers who use that trick all the time!

     foreach (Item item in list) {

        try {

             // do horribly risky stuff to item

        } catch (Throwable t) { }

    }


    If at least 80% or so of the items get processed correctly, nobody will notice!

  • Wile E. Coyote (unregistered) in reply to tmountjr
    tmountjr:
    There are no errors as long as I don't know about them.

    And you can run off the edge of a cliff without falling as long as you don't look down.  Who wrote this software?  ACME?

  • byte_lancer (unregistered)

    When at first you dont succeed, wipe out all traces of failure.

    And redefine success as well. 

     

    Captcha: truthiness ; heh, yea. Very appropriate. 

  • Whiskey Tango Foxtrot? Over. (At Work) (unregistered)

    I read the title and thought:

     

    #define TRUE 0

    #define FALSE 1

     

    I'm glad I was wrong -- this is much more fun.

  • (cs) in reply to Whiskey Tango Foxtrot? Over. (At Work)

    Seen on license-plate-like wall-placard in store window in Times Square:

    "If at first you don't succeed, redefine success"

  • SomeCoder (unregistered) in reply to anon
    anon:

    I've known some programmers who use that trick all the time!

     foreach (Item item in list) {

        try {

             // do horribly risky stuff to item

        } catch (Throwable t) { }

    }


    If at least 80% or so of the items get processed correctly, nobody will notice!

     Haha!  I had to fix some code that did just this type of thing.  The guy tried to manage his own threading in C# and had done it horribly (C# will handle threading for you for the most part if you just tell it to).  Anyway he was trying to clean up a thread or something and did something like this (psuedo-C# here):

    try
    {
         someThread.Exit();
    }
    catch (Exception)
    {
    }

    // go about our business as if the thread had exited normally.

     

    So apparently the FAILURE == SUCCESS  is true for many programmers *shakes head*

  • (cs) in reply to SomeCoder

    This is good one ... I like it.

     WTF++
     

  • Dazed (unregistered)

    So let's get this straight - the vendor was allowed to update the production machine directly? Without going through any form of test environment first? Without informing the company? But when it blew up it was the company's own staff who had to track down the problem?

  • (cs) in reply to Whiskey Tango Foxtrot? Over. (At Work)

    public static int SUCCESS_CODE = 1; 

    public static int ERROR_CODE = SUCCESS_CODE;

  • (cs) in reply to SomeCoder
    Anonymous:
    anon:

    I've known some programmers who use that trick all the time!

     foreach (Item item in list) {

        try {

             // do horribly risky stuff to item

        } catch (Throwable t) { }

    }


    If at least 80% or so of the items get processed correctly, nobody will notice!

     Haha!  I had to fix some code that did just this type of thing.  The guy tried to manage his own threading in C# and had done it horribly (C# will handle threading for you for the most part if you just tell it to).  Anyway he was trying to clean up a thread or something and did something like this (psuedo-C# here):

    try
    {
         someThread.Exit();
    }
    catch (Exception)
    {
    }

    // go about our business as if the thread had exited normally.

    So apparently the FAILURE == SUCCESS  is true for many programmers *shakes head*

    Ponder the thought processes of the person who might have written this:

    Boolean TRUE = Boolean.FALSE;
Boolean FALSE = Boolean.TRUE;
enum Bool { TRUE, FALSE, FILE_NOT_FOUND }
  • Nataku (unregistered) in reply to Dazed

    This is amazingly common in the Financial world.  They vendors even have the gall to bill the companies for the fix, more often than not.

  • anonymous (unregistered) in reply to Dazed

    Anonymous:
    So let's get this straight - the vendor was allowed to update the production machine directly? Without going through any form of test environment first? Without informing the company? But when it blew up it was the company's own staff who had to track down the problem?

     

    Yeah, and then a guy who works for the company who lets this happen, mocks the vending company.  "HaHa- they can't write code!  They're so stupid."

    At least, I think that's what's happening.  I can never be too sure on TDWTF, who exactly is mocking whom. 

     

  • Fanguad (unregistered)

    At the company I work at, "Success" is defined using a slightly expanded definition of success. Fortunately, it's not nearly as bad as the above example. When we deliver our product to our customer, success is defined as "All test cases pass, or a known defect/omission/delay causes them to fail." The key word there is "known." Many of these defects are in our customer's code (which we interface with), and are impossible to work around, so really it's not that absurb. I still get an awful whever I see us saying "50% of the test cases pass... SUCCESS!"

  • my name is missing (unregistered) in reply to Nataku

    The government works this way, so why shouldn't your vendors?

     

  • (cs)
    Alex Papadimoulis:

    [image]The issue with their system lied in its external interface: the Global Logistics Module was erroring out.

    <pointless>

    <rant> 

     I hate to be the troll who picks on grammar but when I read this it hurt. My Problem lied in the incorrect use of lied.

    </rant>

    </pointless>
     

  • (cs)

    Seems to me that we just need to define something along the lines of "truthiness;" perhaps we should call it "successiness."  Maybe "counter-failiness." 

    Nah.

    Anyway, there's nothing new to accepting failure as success.  The public schools do it all the time.

     

  • (cs)

    Now what I'm really saying is obvious isn't it?!?!?!?! I.e read between the lines!

    lol I had a vendor do this once....we are on time and under budget.  No failures.  We have no bugs to report and all is well....

     kudos on the SPI response we need that here!

  • (cs) in reply to codenator

    This would make a great management slogan (you know, for morale-boosting and such):

     "Success is not an option."

     

  • The Dude (unregistered) in reply to anon
    Anonymous:

    I've known some programmers who use that trick all the time!

     foreach (Item item in list) {

        try {

             // do horribly risky stuff to item

        } catch (Throwable t) { }

    }


    If at least 80% or so of the items get processed correctly, nobody will notice!

     No, no, no! It's far better to do:

     

     foreach (Item item in list) {

        try {

             // do horribly risky stuff to item

        } catch (Exception ex)

        {

           #if not DEBUG

          throw; // Exceptions are annoying to debug around

          #endif 

        }

    }

  • (cs) in reply to Ghost Ware Wizard

    Is it just me or that red lamp picture has hypnotizing powers?

  • (cs) in reply to The Dude
    TheDude:

     No, no, no! It's far better to do:

     

     foreach (Item item in list) {

        try {

             // do horribly risky stuff to item

        } catch (Exception ex)

        {

           #if not DEBUG

          throw; // Exceptions are annoying to debug around

          #endif 

        }

    }

    You, sir, are a horrible person. ;)
     

  • (cs) in reply to Fanguad

    I enjoy our company's philosophy of "protect the user from pesky errors that may otherwise make them lose faith in the truthfullness and reliability of our company and cause them to slit their own wrists in desperation and you don't want to be responsible for corporate suicide DO YOU??"

     Actually, that's just my interpretation. I believe the upper-ups call it "Failing Gracefully", or in the more wince-inducing cases "Ignorable Errors".

     IE: When an error occurs that we can't recover from, pop a message-box that tells them there is a problem and to call the company (with no error code, logging, or stack-traces). If it's not a fatal error, we recover from it by pretending it didn't happen.

     They key here is, DON'T PANIC... (the people who pay us).

  • Solo (unregistered)

    This is how you code for enterprisey solutions. They should have been more clear about the web service in the documentation, something like:

    This web service returns a tri-state boolean: True, False, ERROR_SUCCESS

     

    Captcha: paula
     

  • Nachoo (unregistered) in reply to Solo

    I agree, the picture has hypnotizing magic

     

    captcha: genius  - No, not really.


     

  • (cs)

    The software worked just like it was supposed to. This is more of a WTF/TCTFM (They Changed The Fine Manual)

  • (cs) in reply to anon
    Anonymous:

    I've known some programmers who use that trick all the time!

     foreach (Item item in list) {

        try {

             // do horribly risky stuff to item

        } catch (Throwable t) { }

    }


    If at least 80% or so of the items get processed correctly, nobody will notice!


    I've got some code that does almost exactly that:

    foreach $task (@list)
    {
        exec
        {
            #Interface with a web server to do an operation that's got a decent chance of failing
        }
    }

    Since most of the failures are due to transient failures of the web server, and tasks will move off the list after a period of time, it's acceptable to just ignore the error and try again the next time the list is processed.
  • (cs) in reply to Carnildo
    Carnildo:
    Anonymous:

    I've known some programmers who use that trick all the time!

     foreach (Item item in list) {

        try {

             // do horribly risky stuff to item

        } catch (Throwable t) { }

    }


    If at least 80% or so of the items get processed correctly, nobody will notice!


    I've got some code that does almost exactly that:

    foreach $task (@list)
    {
        exec
        {
            #Interface with a web server to do an operation that's got a decent chance of failing
        }
    }

    Since most of the failures are due to transient failures of the web server, and tasks will move off the list after a period of time, it's acceptable to just ignore the error and try again the next time the list is processed.

    Most people seem to have missed the point. Specific failures where not ignored. That can be acceptable.

    The WTF is that ALLLLL 403 errors in the application are ignored.
     

  • No (unregistered) in reply to Whiskey Tango Foxtrot? Over. (At Work)
    Anonymous:

    I read the title and thought:

     

    #define TRUE 0

    #define FALSE 1

     

    I'm glad I was wrong -- this is much more fun.

     

    #define TRUE 1

    #define FALSE 1

  • 57451 (unregistered)

    What's the problem? Just wrap it in a "try {} catch(Throwable t) {}" -block and let it loop 5000 times if it fails...

     

    Captcha: pizza? 

  • Jon (unregistered) in reply to codenator
    codenator:
    <pointless>

    <rant> 

     I hate to be the troll who picks on grammar but when I read this it hurt. My Problem lied in the incorrect use of lied.

    </rant>

    </pointless>

    You appear to have an awkward markup structure. It should read, '<rant type="pointless">'.
  • (cs) in reply to CodeReaper
    CodeReaper:

    I enjoy our company's philosophy of "protect the user from pesky errors that may otherwise make them lose faith in the truthfullness and reliability of our company and cause them to slit their own wrists in desperation and you don't want to be responsible for corporate suicide DO YOU??"

     Actually, that's just my interpretation. I believe the upper-ups call it "Failing Gracefully", or in the more wince-inducing cases "Ignorable Errors".

     IE: When an error occurs that we can't recover from, pop a message-box that tells them there is a problem and to call the company (with no error code, logging, or stack-traces). If it's not a fatal error, we recover from it by pretending it didn't happen.

     They key here is, DON'T PANIC... (the people who pay us).

    This actually makes sense. Well, sort of.

    Users _do_ panic when they see an error message, usually to the extent that they forget to read the error message, press printscreen or produce any kind of sensible reaction.

    Therefore I don't see much point in annoying them with stack traces or debug infos, those are meant to be read by developers and should be sent directly to them. (Or at least saved to disk or something.)

    A single sentence of error message will suffice in most cases.

     

  • (cs) in reply to Dazed

    Anonymous:
    So let's get this straight - the vendor was allowed to update the production machine directly? Without going through any form of test environment first? Without informing the company? But when it blew up it was the company's own staff who had to track down the problem?

    Some places I've worked in the past have had an "auto-update" feature turned on.  Like Windows' one.  Good fun when they slip something like this WTF through unannounced.

  • Robin Munn (unregistered)

    The issue with their system lied in its external interface:

    That's the most unintentionally beautiful grammatical error I've ever seen. Yes, that should have been "the issue ... lay in its external interface." But there's another way to correct it: remove the first three words of the sentence. Behold:

    "Their system lied in its external interface."

    Yes. Yes, indeed, it did. :-)

  • Joe Mason (unregistered)

    Ok, I'm sick of going back and fixing it every time this text box eats a space.  Ifthis post is badly formatted, it's not my fault.  Seriously, WTF?  There are thousands of BB systems on the net, why is this one the onlyone that sucks?

    Aha, they're using libcurl!  (Or at least, I've run into this exact problem with libcurl.)

    The curl function to download a file has, as you'd expect, errorcodes andmethods to get the associated messages and all that good stuff.  But, non-intuitively, they only return errors returned by curl itself (like "operation timed out" or "invalid parameters"). If the HTTP request returns an HTTP error, youget a result that looksjust fine,except the page contents are a simple 404(or whatever)page and the code isn't 200.

    So the obvious way to use curl, which is tojust call the download function and check the return value, assuming that your library will helpfully translate HTTP return codes, is wrong - you have to do two error checks, once for libcurl errors and once for the actual HTTP errors.  Needless to say, there's lots of hurriedly written code that doesn't bother, especially in projects which are mainly not web-related at all andonly contain one lousy routine to fetch a status page from somewhere.

    So this vendor probably used either libcurl or something else that works the same way, and just noticedand fixed this obvious bug in it - which was hiding the real bug, which is that the page it was depending on didn't work. The "correct" fix would be to take that whole module outof the system, since it's not being used, or at least mark it optional so that errors it causes won't bring the whole system down - but thefast and easy fix is just to revert the "fix" that mucked everything up.

  • (cs) in reply to anon
    Anonymous:

    I've known some programmers who use that trick all the time!

     foreach (Item item in list) {

        try {

             // do horribly risky stuff to item

        } catch (Throwable t) { }

    }


    If at least 80% or so of the items get processed correctly, nobody will notice!

    +1, Insightful

     

  • (cs)

    Reminds me of a function a co-worker of mine once wrote:

     

    if (value==true)
    {

        return true;

    }
    else
    {

        return 1;

    }

    Hehe... another co-worker reminded me of the code that this same guy wrote that was really cool because it didn't have bugs

    'Suppress errors until batch has finished processing
    Try

        'Perform Task

    Catch ex As Exception

       'Do Nothing

    End Try

  • (cs) in reply to lomaxx
    lomaxx:

    Reminds me of a function a co-worker of mine once wrote:

     

    if (value==true)
    {

        return true;

    }
    else
    {

        return 1;

    }

    I love these :)

    When I'm working on some legacy code I frequently change these kinds of statements to their "normal" counterparts.

    I'd try to convert it to something like: return value ? true : 1; but I've not heard of a type called a "boolint" :)

    Maybe it could be like this:

    enum boolint
    {
      true,
      false,
      1,
      FileNotFound
    }

  • Anon E Moose (unregistered) in reply to KattMan

    And remember, if we don't succeed, we run the risk of failure!

     

  • Jon (unregistered) in reply to Samah
    Samah:
    Maybe it could be like this:

    enum boolint
    {
      true,
      false,
      1,
      FileNotFound
    }

    Don't forget VeryNull.
  • Dom (unregistered)

    "The issue with their system lied in its external interface"

     Grammar nitpicking: 'to lie', meaning 'to place', is an irregular verb. The past tense of it is 'lay'. 'To lie', meaning 'to deceive', is more regular: it has 'lied' as the past tense.

    So, when I read that sentence, I thought the problem was that the external interface was lying. Which was (unintentionally, I think) true!

  • Jon (unregistered) in reply to Dom
    Anonymous:

     Grammar nitpicking: 'to lie', meaning 'to place', is an irregular verb. The past tense of it is 'lay'. 'To lie', meaning 'to deceive', is more regular: it has 'lied' as the past tense.

    Internet nitpicking: you are at least the third person to point this out.
  • PHP coder (unregistered)

    I used to get this error in WorldCraft all the time when it tried to copy a file that didnt exist:

    Error: The command completed succesfully. 

     

    CAPTCHA: shut the fuck up 

  • (cs) in reply to CodeReaper
    CodeReaper:

    I enjoy our company's philosophy of "protect the user from pesky errors that may otherwise make them lose faith in the truthfullness and reliability of our company and cause them to slit their own wrists in desperation and you don't want to be responsible for corporate suicide DO YOU??"

     Actually, that's just my interpretation. I believe the upper-ups call it "Failing Gracefully", or in the more wince-inducing cases "Ignorable Errors".

     IE: When an error occurs that we can't recover from, pop a message-box that tells them there is a problem and to call the company (with no error code, logging, or stack-traces). If it's not a fatal error, we recover from it by pretending it didn't happen.

     They key here is, DON'T PANIC... (the people who pay us).

     

    Might as well give them error code 42 for every one of those errors.

  • (cs) in reply to Jon
    [image] codenator:
    <pointless>

    <rant> 

     I hate to be the troll who picks on grammar but when I read this it hurt. My Problem lied in the incorrect use of lied.

    </rant>

    </pointless>

    You appear to have an awkward markup structure. It should read, '<rant type="pointless">'.

     

     

     

    Don't forget the SOAP wrapper.

  • (cs)

    I have had a situation before where I was responsible for writing the system test plan and testing my own code.

    If I had read this story before hand, I could have saved myself so much drama. I'll remember this in future, thanks.

  • JWick (unregistered) in reply to PHP coder
    Anonymous:

    I used to get this error in WorldCraft all the time when it tried to copy a file that didnt exist:

    Error: The command completed succesfully. 

     

    CAPTCHA: shut the fuck up 



    I always wondered how they could get these kinds of error messages until i got one in a soft i wrote. 
    I remember saying out loud in the office : "WTF !! Error: No Error ??"
    My coworkers came to check and we had a good laugth :D

Leave a comment on “Define Failure As Success”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article