Comment On Define Failure As Success

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?

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.

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

War is peace.

Freedom is slavery.

Bugs are features.

Failures are sucessess.

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

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!

tmountjr:

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

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

And redefine success as well. 

 

Captcha: truthiness ; heh, yea. Very appropriate. 

I read the title and thought:

 

#define TRUE 0

#define FALSE 1

 

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

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

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

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*

This is good one ... I like it.

 WTF++
 

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?

public static int SUCCESS_CODE = 1; 

public static int ERROR_CODE = SUCCESS_CODE;

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 }

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:

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. 

 

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!"

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

 

wtf?

> dig axfr initech.com @ns.initech.com

 ;; global options:  printcmd
initech.com.            3600    IN      TXT     "Initech Co., Ltd."
initech.com.            3600    IN      A       61.74.133.2
initech.com.            3600    IN      MX      10 watcher.initech.com.
aix.initech.com.        3600    IN      A       61.74.133.7
aragorn.initech.com.    3600    IN      A       61.74.133.242
assa.initech.com.       3600    IN      A       61.74.133.28
blog.initech.com.       3600    IN      A       61.74.133.55
board.initech.com.      3600    IN      A       61.74.133.55
bt.initech.com.         3600    IN      A       61.74.133.33
bugs.initech.com.       3600    IN      CNAME   stdin.initech.com.

....... 

apperently bugs always come from stdin ?!

only I see no edi ;) 

 lets see what teay have on jsptest and phptest.initech..... *g*

Alex Papadimoulis:

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>
 

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.

 

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!

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

 "Success is not an option."

 

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 

    }

}

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

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. ;)
 

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 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
 

I agree, the picture has hypnotizing magic

 

captcha: genius  - No, not really.


 

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

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!

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.
 

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.

I do the same thing when raising events.  If one handler blows up,no other handler receives the event. (from memory);

void RaiseEvent(Delegate d, params object[] args) {

    foreach(Delegate handler in d.GetInvocationList()){

       try{

           handler.DynamicInvoke(args);

       } catch { } 

   } 

} 

Rick:

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.
 

 

NoNoNo - not ignored.  According to the vendor 403 failures are defined as

"success" but a mistake in the production code defined failures as failures. 

 

This has been  corrected.

 

Clear now? 

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

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? 

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">'.

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.

 

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.

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. :-)

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.

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

 

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

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
}

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

 

Samah:

Maybe it could be like this:

enum boolint
{
  true,
  false,
  1,
  FileNotFound
}

Don't forget VeryNull.

"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!

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.

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 

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.