The Daily WTF: Curious Perversions in Information Technology

2010-09-01 Reply Admin

Buddy:

The Nerve:

Fixed?

private void SetAccount(RequisitionData.RequisitionItem requisitionItem, 
                        AccountData.Account account)
{
	requisitionItem.AccountID = account.ID;
        requisitionItem.AccountCode = account.Code;
}

Does it need checks for parameters being null?

Fixed?

private void SetAccount(RequisitionData.RequisitionItem requisitionItem, 
                        AccountData.Account account)
{
   try {
	requisitionItem.AccountID = account.ID;
        requisitionItem.AccountCode = account.Code;
   } catch (NullPointerException e) {}
}

2010-09-01 Reply Admin

Hmm... Someone deleted the "how to gracefully fail on NULL" thread?!?

I had intended for my previous answer of emulating SQL's null logic (any 'operation' on a null operand would return a null result, except for specific comparison methods) to be a discussion generator, since i'm actually interested to see what potential drawbacks this strategy might have...

2010-09-01 Reply Admin

airdrik:
bene:
> As for what should be done when you try to use a reference to null;
Then I have to ask; in a language where primitives are not allowed to be null, why are references allowed to be null ?
because you might actually want to represent something that has no value (member not initialized or member explicitly unset). That's one thing I found annoying when working in a c# application that we have is that Dates are value types and can't be set to null, so if there is no maturity date on the transaction then you have to set it to a magic value which means null. Either that or you create your own NullableDate as a reference type just so that you can set it null.

Wouldn't DateTime.MaxValue be a valid choice for no maturity date?
Isn't null just another "magic value" anyway?
There's a default "NullableDate" type in .Net (since 2.0 iirc); it's called "DateTime?". ;-)

SwampJedi · 2010-09-01 Reply Admin

by:
That's what you get when you have scientists coding.
"If this statement was correct, the following would happen. This statement is not correct, therefore it will not."

Electronics engineers, but I agree. It was very ad-hoc. I suppose the thought was "Oh, it's just software, we can do that."

frits · 2010-09-01 Reply Admin

airdrik:
bene:
> As for what should be done when you try to use a reference to null;
Then I have to ask; in a language where primitives are not allowed to be null, why are references allowed to be null ?
because you might actually want to represent something that has no value (member not initialized or member explicitly unset). That's one thing I found annoying when working in a c# application that we have is that Dates are value types and can't be set to null, so if there is no maturity date on the transaction then you have to set it to a magic value which means null. Either that or you create your own NullableDate as a reference type just so that you can set it null. Then there's also the trouble with value types in data sets - if you access a value that is unset you get an exception, so you have to wrap such access in:
if(!dataSetRow.isValueNull())
{
//use dataSetRow.Value
}
xP

As far as value types in C# go, you can just use the "?" operator to make an value-type object nullable.

e.g.

    DateTime? nullableDateTime = null;

chrismcb · 2010-09-01 Reply Admin

FuBar:
I think this is just a simple bug, not a WTF. The first "else" should set to false, not true. It's perfectly legitimate to not allow an automated update process to blithely overwrite known good data with possibly bad data, though this is not the ideal way to prevent it. The sales reps in this company are probably still wondering why they're getting complaints from customers that packages are going to stale addresses; the customers are probably saying "you had it right for a while, why are you using my old address again??? This is the fourth time I've told you to change it!"

And this is exactly why it is a WTF. You've already had a half dozen people claim you could reduce the code to two lines. IF this was a bug, you just made it worse by ripping out all the unused logic.

But if it isn't a bug (or the specs changed and all code paths should be set to true) then it is a WTF for leaving complicated code in. The code is complicated enough and hard enough to maintain, don't make it more complicated with unused logic.

TRWTF is some people don't think this is a WTF

2010-09-01 Reply Admin

chrismcb:
FuBar:
I think this is just a simple bug, not a WTF. The first "else" should set to false, not true. It's perfectly legitimate to not allow an automated update process to blithely overwrite known good data with possibly bad data, though this is not the ideal way to prevent it. The sales reps in this company are probably still wondering why they're getting complaints from customers that packages are going to stale addresses; the customers are probably saying "you had it right for a while, why are you using my old address again??? This is the fourth time I've told you to change it!"

And this is exactly why it is a WTF. You've already had a half dozen people claim you could reduce the code to two lines. IF this was a bug, you just made it worse by ripping out all the unused logic.

But if it isn't a bug (or the specs changed and all code paths should be set to true) then it is a WTF for leaving complicated code in. The code is complicated enough and hard enough to maintain, don't make it more complicated with unused logic.

TRWTF is some people don't think this is a WTF

TRWTF is that some people think this is Java.

2010-09-01 Reply Admin

NullPointerException:

And of course:

if (Paula.isBrillant())
    allowSetAccount = true;
else // Unreachable code path
    allowSetAccount = true;

Fucking amazing that people still remember Paula! It's been what, 5 years since she was on this site?

2010-09-01 Reply Admin

by:
SwampJedi:
I've had the honor of trying to maintain a 250k line FORTRAN77 codebase that was almost 30 years old. I came across several gems like this. These were almost always the result of new/changed requirements that were implemented without any thought of refactoring.
This from the same group of folks who routinely commented out code by wrapping it in a conditional that would always evaluate to false, with no documentation.
That's what you get when you have scientists coding.

"If this statement was correct, the following would happen. This statement is not correct, therefore it will not."

SPICE?

2010-09-01 Reply Admin

might as well add some things to confuse the reader as well

else if (0)
    allowSetAccount = false;
else if (1==2)
    allowSetAccount = false;

and so forth

2010-09-01 Reply Admin

magik:
might as well add some things to confuse the reader as well
else if (0)
    allowSetAccount = false;
else if (1==2)
    allowSetAccount = false;
and so forth

I could live with this as a featured comment.

dtaylor84 · 2010-09-01 Reply Admin

Well, assuming Java (and no operator overloading):

private void SetAccount(RequisitionData.RequisitionItem requisitionItem, 
                        AccountData.Account account, bool automation)
{
    if (account == null)
        return;

    if (automation)
        requisitionItem.IsAccountCodeNull(); // side-effects?

    requisitionItem.AccountID = account.ID;
    requisitionItem.AccountCode = account.Code;
}

Obviously, if you know IsAccountCodeNull() has no side effects, you can eliminate that, too.

2010-09-01 Reply Admin

These psuedo-logic control-flow-begging-to-be-deleted snippets are my favorite WTFs. This one from our codebase isn't that bad but I still got a chuckle from it:

private function getStatus($status_code, $status_display_as)
{
    if ($status_code == $status_display_as)
    {
        return $this->getStatusInfo($status_code);
    }
    else {
        return $this->getStatusInfo($status_display_as);
    }
}

As a friend of mine said, "IF ELSE: UR DOIN IT WRONG"

2010-09-01 Reply Admin

So they set some properties in a copy of requisitionItem. Yeah you can do that, but later when they try to use it wonder why the properties aren't really set.

Should have passed ref requisitionItem

2010-09-01 Reply Admin

Jay:
NullPointerException:
hatterson:
Anyway, should the compiler optimize that all out anyway?
Any decent optimizing compiler would.

Hmm, I wonder about that.

It can't optimize out the call to isAccountCodeNull unless the optimizer is smart enough to figure out that this function has no side effects. In some cases that would be easy to figure out but in the general case? Wow.

Given that it must call that function, it must do the test on automation because it only calls isAccountCodeNull when automation is true.

As a human being looking at this code, I can easily see that the test on requisitionItem.AccountCode is superfluous, because I notice that the body of the IF is identical to the body of the ELSE. Are optimizing compilers smart enough to figure that out? Sure, in the simple case where the body is only one line that's easy. But what if the body is longer? How far does it check? Would it check for only character-for-character identical code or would it look for functionally identically, like "x++;" is the same as "x=x+1;", or calling a fuction with parameter "false" is the same as calling the function with a variable that has been set to false? Etc. I freely admit that I don't know if compilers are smart enough to do this sort of optimization. I'd be interested to know how far the state of the art on this has progressed.

So the only safe optimization that I see a compiler being likely to be able to figure out is to eliminate the "if (allowSetAccount)" around the last two statements. I can see that a compiler could figure out that the flag is always true by that point and thus eliminate the test.

I'd be interested to hear if someone who knows more about optimizing compilers can tell us just how much they can actually accomplish these days.

Compilers don't look at the text at all. They look at the generated AST that is unambiguous.

Although you are correct about the side effect issue.

2010-09-01 Reply Admin

BadFellas.org:
NullPointerException:
And of course:
if (Paula.isBrillant())
    allowSetAccount = true;
else // Unreachable code path
    allowSetAccount = true;
Fucking amazing that people still remember Paula! It's been what, 5 years since she was on this site?

And she's referenced, what, every other day in the comments?

2010-09-01 Reply Admin

BadFellas.org:
NullPointerException:
And of course:
if (Paula.isBrillant())
    allowSetAccount = true;
else // Unreachable code path
    allowSetAccount = true;
Fucking amazing that people still remember Paula! It's been what, 5 years since she was on this site?

Yes but her "brillancy" is eternal.

da Doctah · 2010-09-01 Reply Admin

C:
E.g., IMO, "++x", "x++", "x=x+1", and "x=1+x" should all compile into "INC x", so they would all match.

They'd better not match. What if x is a function call?

2010-09-01 Reply Admin

Jonathan:
These psuedo-logic control-flow-begging-to-be-deleted snippets are my favorite WTFs. This one from our codebase isn't that bad but I still got a chuckle from it:
private function getStatus($status_code, $status_display_as)
{
    if ($status_code == $status_display_as)
    {
        return $this->getStatusInfo($status_code);
    }
    else {
        return $this->getStatusInfo($status_display_as);
    }
}
As a friend of mine said, "IF ELSE: UR DOIN IT WRONG"

I've met a few people who are responsible for this type of code.

It's amazing (troubling) to listen to them go on and on about how their solution is better and more flexible than the simplified/refactored method. They will contend that in the long run, if anyone ever needs to change it, having the code written this way will save boatloads of time/thinking/testing.

As a result, you get bloated, overly-and-unnecessarily-complex codebases, much like the one the submitter is describing.

psiphiorg · 2010-09-01 Reply Admin

da Doctah:
C:
E.g., IMO, "++x", "x++", "x=x+1", and "x=1+x" should all compile into "INC x", so they would all match.
They'd better not match. What if x is a function call?

Then they would be written "++x()", "x()++", "x()=x()+1", or "x()=1+x()", each of which would be a compile-time error in most languages that I know. But even if you were using a language where function calls can be lvalues, then none of those would compile to "INC x".

davidh

2010-09-01 Reply Admin

In C++, the following definition of x() makes those statements compile just fine:)

int y = 0; int &x() { return y; }

This is why I don't do C or C++ any longer.

hoodaticus · 2010-09-01 Reply Admin

Out of curiosity:

do you guys think it's bad to slap IEnumerable onto all of your delegator classes (so that their delegatees can be accessed)? I think the for each loop and shorter iteration code when I consume the class later makes it worth it, but I wonder what other people think.

In my context, I do a lot of API writing for internal consumption (in mission-critical apps), and I suspect someone lower on the food chain will have to maintain this crap in future years. Do you think it's business-justified?

2010-09-01 Reply Admin

So why does he start off with "architectural complexity" and large projects etc. and then all this is is some unnecessary code, which is either a leftover nobody dares fix or some misguided attempt to foresee the future? Where's the architectural complexity here? Where are the layers upon layers upon layers that are not needed?

DaveK · 2010-09-01 Reply Admin

snoofle:

Imagine the possibilities with all the other potential things to test for:

if (FILE_NOT_FOUND) 
   allowSetAccount = true;
else if (System.currentTimeMillis() > 12345)
   allowSetAccount = true;
else if (System.getProperties().getProperty("os.name").equals("Windows")
   allowSetAccount = true;
else if (!System.getProperties().getProperty("os.name").equals("Windows")
   allowSetAccount = true;
else if (42)
   allowSetAccount = true;
// This could go on for a while...

Yes, in fact it could go on infinitely long it seems; in my testing, no matter how many clauses I added on the end, the final executable remained the same size! You're a genius, you've invented constant-output-size compression!

I've already written a compressor that takes any arbitrary file, encodes it as a bunch of C statements and appends them inside a new else...if clause on the end of your sample code, then passes it through a compiler, and it works brillantly! I'm having a little trouble debugging the decompressor, but I'm sure I'll be able to figure it out soon enough. Anyone got any venture funding...?

2010-09-01 Reply Admin

C:
Hmm... Someone deleted the "how to gracefully fail on NULL" thread?!?

Yeah, someone.

Actually, why? There was no spam, trolling or dead horses in them (at least in the first few messages I saw before they were deleted).

Is it because they mentioned "heretic" languages such as C++ and discussing how they're different, and perhaps sometimes better than TPTB's favorite languages?

Well, I must say the quality of this site is really going downhill lately. First the articles, full of non-WTFs and bad copy editing, then the comments turning into a troll/meme fest, and now censorship(?), in one of the few threads with actual content (and perhaps interesting discussion).

Yes, I know, an unregistered user shouldn't complain, but in this situation I don't really feel like registering. And I also expect this comment will be deleted.

2010-09-01 Reply Admin

javac does very little optimization, it just translates into Java bytecode. The actual optimization happens in the runtime compiler, where it has access to the machine architecture that it is running on as well as the execution profile of the code. The runtime compiler will definitely take the unneeded branches out, and (since it has access to the code as it's actually running) can also verify that any method calls have no side effects.

Unfortunately, there isn't really a good way to observe the results of the runtime compilation, but you may be able to see the difference in speed for "always false" vs. "randomly true or false".

2010-09-02 Reply Admin

Tbh, this looks like the business rules have been changed over the years. The code is very precise, clear structured and well documented. So yeah... You will always find something like this in any code in a changing domain.

2010-09-02 Reply Admin

by:
SwampJedi:
....
That's what you get when you have scientists coding.
"If this statement was correct, the following would happen. This statement is not correct, therefore it will not."

I hope that scientist don't use that kind of logic: p -> q does NOT imply -p -> -q

2010-09-02 Reply Admin

Fred:
TheCPUWizard:
....barring side effects, operator overloading...
And that is something which should never be discounted. There are good reasons to justify making the minimal changes required to achieve the goal. Without examining other code, it is impossible to tell if anything is "really" happening behind the scenes.
What??! I thought the glorious promise of the much touted object oriented paradigm was that other code can't mess with my stuff.

If you make a method that shouldn't mutate object state still mutate object state, it's not *other* code that messes with your stuff, it's your own.

2010-09-02 Reply Admin

The Nerve:

Buddy:

The Nerve:

Fixed?

private void SetAccount(RequisitionData.RequisitionItem requisitionItem, 
                        AccountData.Account account)
{
	requisitionItem.AccountID = account.ID;
        requisitionItem.AccountCode = account.Code;
}

Does it need checks for parameters being null?

Fixed?

private void SetAccount(RequisitionData.RequisitionItem requisitionItem, 
                        AccountData.Account account)
{
   try {
	requisitionItem.AccountID = account.ID;
        requisitionItem.AccountCode = account.Code;
   } catch (NullPointerException e) {}
}

You best be trolling, boy.

Cbuttius · 2010-09-02 Reply Admin

C:
Hmm... Someone deleted the "how to gracefully fail on NULL" thread?!?
I had intended for my previous answer of emulating SQL's null logic (any 'operation' on a null operand would return a null result, except for specific comparison methods) to be a discussion generator, since i'm actually interested to see what potential drawbacks this strategy might have...

Yes, a lot of the discussion about the difference between handling nulls in Java, C# and C++ were deleted. This was a discussion, not spam, and should not have been deleted off. Whilst not directly related to the article, it was a spin-off discussion about the check for null in the function (the one check it appears we need to retain).

I am getting fed up of the over-moderation here. The comments are a conversation that starts with the article and are not necessarily our opinions of the article. It is fun also making comments on what the people above you have posted.

Not sure what he wants us to post exactly. Surely everyone can see what the WTF is and what a better solution would be. If it's not obvious to everyone reading it's not a WTF.

TheJasper · 2010-09-02 Reply Admin

C:

E.g., IMO, "++x", "x++", "x=x+1", and "x=1+x" should all compile into "INC x", so they would all match.

no. ++x x++ may behave very differently.

http://en.wikipedia.org/wiki/Increment_operator#Increment_operator

I prefer x++ simply because it is the most used form. Even if you think ++x is better you should assume the next programmer is a self taught programmer who learned [c|Java|C#|...] from a ... for dummies book last night while waiting for his illegal porn torrents to finish downloading.

MrBester · 2010-09-02 Reply Admin

TheJasper:
I prefer x++ simply because it is the most used form. Even if you think ++x is better you should assume the next programmer is a self taught programmer who learned [c|Java|C#|...] from a ... for dummies book last night while waiting for his illegal porn torrents to finish downloading.

Which is one excellent reason for why I like it and have absolutely no qualms about using it wherever the mood takes me.

2010-09-02 Reply Admin

da Doctah:
C:
E.g., IMO, "++x", "x++", "x=x+1", and "x=1+x" should all compile into "INC x", so they would all match.

They'd better not match. What if x is a function call?

Then the compiler would complain about your trying to assign to it? ;;-)

2010-09-02 Reply Admin

TheJasper:
...assume the next programmer is a self taught programmer who learned [c|Java|C#|...] from a ... for dummies book...

Why should I give a crap if the next programmer is a moron? That's his problem, I'm not dumbing down my code to cater for idiots.

frits · 2010-09-02 Reply Admin

Anonymous:
TheJasper:
...assume the next programmer is a self taught programmer who learned [c|Java|C#|...] from a ... for dummies book...
Why should I give a crap if the next programmer is a moron? That's his problem, I'm not dumbing down my code to cater for idiots.

Exactly. He's going to dumb it down anyway. Why do his work for him?

2010-09-02 Reply Admin

TheJasper:
C:
E.g., IMO, "++x", "x++", "x=x+1", and "x=1+x" should all compile into "INC x", so they would all match.
no. ++x x++ may behave very differently.
http://en.wikipedia.org/wiki/Increment_operator#Increment_operator

I prefer x++ simply because it is the most used form. Even if you think ++x is better you should assume the next programmer is a self taught programmer who learned [c|Java|C#|...] from a ... for dummies book last night while waiting for his illegal porn torrents to finish downloading.

Well, that's a bit beside the point, since i was talking about /instructions/, not out-of-context expressions, and those would obviously discard the "result".

But now that you've mentioned the subjectivity of that choice, i really like the "++x" form, since it doesn't need to save the "pre" value and pass it as result. The memory and speed saves are minimal, i concede, but why choose waste simply because "everybody else does it"? :) I fail to see the relevance of that "self-taught" "next guy": if he doesn't know of preincrementing, he should learn about it.

hatterson · 2010-09-02 Reply Admin

C:
E.g., IMO, "++x", "x++", "x=x+1", and "x=1+x" should all compile into "INC x", so they would all match.

You're right that each of those will result in "INC x"

However the issue with ++x and x++ is when nested in larger statements.

y = x++; vs. y = ++x;

The result would be the equivalent of y=x x=x+1 vs. x=x+1 y=x

Which means your INC x is either before or after your assignment.

Either way it's really all beside the point.

The real question is, when an optimizer is fed a branch where both branches result in the same code (whether they look the same or not), will it remove the branch.

Obviously in a case like if (doesErrorExist() == true) then return true; else return true; if should NOT optimize it out as doesErrorExist() results in a code jump that may have side effects.

But in the case of bool isError = doesErrorExist(); if (isError == true) then return true; else return true; there is no code jump during the evaluation of the conditional so no chance of side effects and it could be 'safely' optimized out.

Now obviously I'm not suggesting the approach of "well it doesn't matter since the compiler will optimize it away" as it is very bad form to leave superfluous code in place simply because you're too lazy to remove it (especially from a maintenance standpoint) however code like this might have a good reason for staying in the code base, although it really should be commented if it's left in this form so that future devs don't say "oh hey this is pointless lemme delete it."

Markp · 2010-09-02 Reply Admin

NullPointerException:
hatterson:
Anyway, should the compiler optimize that all out anyway?
Any decent optimizing compiler would.

No. To optimize that out would require the compiler proving that all current and future implementations of all of those methods (IsAccountCodeNull(), etc) to not have any side-effects.

I know Java doesn't have any language construct that would guarantee that, and I highly doubt C++ or C# would either.

It could optimize out some of the branches, but not the method calls outright.

2010-09-02 Reply Admin

frits:
Anonymous:
TheJasper:
...assume the next programmer is a self taught programmer who learned [c|Java|C#|...] from a ... for dummies book...
Why should I give a crap if the next programmer is a moron? That's his problem, I'm not dumbing down my code to cater for idiots.

Exactly. He's going to dumb it down anyway. Why do his work for him?

You are an idiot and should be banned from using your mommy and daddy's modem.

frits · 2010-09-02 Reply Admin

Bert Glanstron:
frits:
Anonymous:
TheJasper:
...assume the next programmer is a self taught programmer who learned [c|Java|C#|...] from a ... for dummies book...
Why should I give a crap if the next programmer is a moron? That's his problem, I'm not dumbing down my code to cater for idiots.

Exactly. He's going to dumb it down anyway. Why do his work for him?

You are an idiot and should be banned from using your mommy and daddy's modem.

Your slippin'. It took you 12 minutes. Too much partying last night?

2010-09-02 Reply Admin

boog:
wtf:
boog:
A bug isn't a WTF?

Nope.
I should rephrase.

"A bug can't be a WTF?"

That's better. Continue.

Actually no. You would think it would, but a bug is a failure on the part of the developer, and a WTF is something Worse Than Failure. This implies that it's not just a failure which a bug is.

captcha: decet -- Are there any decet developers here?

hatterson · 2010-09-02 Reply Admin

Markp:
NullPointerException:
hatterson:
Anyway, should the compiler optimize that all out anyway?
Any decent optimizing compiler would.

No. To optimize that out would require the compiler proving that all current and future implementations of all of those methods (IsAccountCodeNull(), etc) to not have any side-effects.

I know Java doesn't have any language construct that would guarantee that, and I highly doubt C++ or C# would either.

It could optimize out some of the branches, but not the method calls outright.

Correct, however it should be able to turn.

if (IsAccountCodeNull()) return true; else return true;

into

IsAccountCodeNull(); return true;

frits · 2010-09-02 Reply Admin

highphilosopher:
boog:
wtf:
boog:
A bug isn't a WTF?

Nope.
I should rephrase.

"A bug can't be a WTF?"

That's better. Continue.

Actually no. You would think it would, but a bug is a failure on the part of the developer, and a WTF is something Worse Than Failure. This implies that it's not just a failure which a bug is.

captcha: decet -- Are there any decet developers here?

Two things:

"Worse Than Failure" is a backronym. I think we all know what WTF stands for.
The code in the article is no more a bug than an inefficient algorithm is a bug. A bug just means an unexpected or incorrect result. This code is just an example of superfluous logic.

To answer Mr Boog's question: A bug can be a WTF and a WTF may not be a bug.

Cbuttius · 2010-09-02 Reply Admin

It's not a bug it's a FEATURE

2010-09-02 Reply Admin

frits:
Two things: 1. "Worse Than Failure" is a backronym. I think we all know what WTF stands for.

"Backronym"? Thanks very much, I just vomited. I hope you're happy with yourself. Most of it went in the trash can. Bastard.

2010-09-02 Reply Admin

TheCPUWizard:
....barring side effects, operator overloading...

And that is something which should never be discounted. There are good reasons to justify making the minimal changes required to achieve the goal. Without examining other code, it is impossible to tell if anything is "really" happening behind the scenes.

Also the compiler is unlikely to optimize this out of existance unless it too can evaluate all of the called code (and the code which that calls, and the code....)

Overloading a comparison operator to have side effects is a WTF.

2010-09-02 Reply Admin

"any 'operation' on a null operand would return a null result,..."

That's where I was going when I asked "why references but not primatives?".

Shouldn't anything be nullable, passing and assigning null without trouble. Then you check "not null" when the result is important.

2010-09-02 Reply Admin

highphilosopher:
boog:
wtf:
boog:
A bug isn't a WTF?

Nope.
I should rephrase.

"A bug can't be a WTF?"

That's better. Continue.

Actually no. You would think it would, but a bug is a failure on the part of the developer, and a WTF is something Worse Than Failure. This implies that it's not just a failure which a bug is.

captcha: decet -- Are there any decet developers here?

Given your overly generic definition of a bug*, you're saying that a failure on the part of the developer is never "a WTF?"

Hold on a minute.

Don't move, just wait right there.

Hmm... let's see... ahh... Ah! Here we are! One of my old favorites:

http://thedailywtf.com/Articles/Seriously,_I_0x27_m_A_Genius.aspx

Now that is a failure on the part of the developer, and it is "a WTF." Your move.

A bug, or defect, is actually any unanticipated deviation from the specification or the user's expectations.

frits · 2010-09-02 Reply Admin

wtf:
frits:
Two things: 1. "Worse Than Failure" is a backronym. I think we all know what WTF stands for.

"Backronym"? Thanks very much, I just vomited. I hope you're happy with yourself. Most of it went in the trash can. Bastard.

It's a real word, Wikipedia told me so.

You're welcome. I hope you didn't have milk this morning.

Accounting for Complexity

Leave a comment on “Accounting for Complexity”