Beautiful code! I mean, if you program for an enterprise, one of the ways to secure your job is to generate few hundred thousand lines of crap like that and have enterprise heavily use the end product (you need to make it work first).
Then you will become indispensable. Managers will never know if your code is unmaintainable because software you wrote is inherently complicated or because you are an "awesome" programmer. New coders hired to maintain your codebase will admit failure quickly, or propose costly "total rewrites", so it becomes cheaper to keep you around.
Sadly, all this from experience on the receiving end. We ended up throwing away similar code and firing original developers, but we spent ungodly amounts of time at meetings first.
Its a perfect storm. Lots of lines of LOC indicating massive productivity, complete unintelligibility to other coders indicating your rock-star status, and a completely intractable architecture guaranteeing your job security.
Sadly, its a word for word take of a little pamphlet on productivity I got on the first day of a consulting gig in 2003. At first I thought it was hilarious, then I tried to explain it to them, then I took to using it ironically like a grown man in Vision skatewear, then in a sad bit of learned helplessness it stuck in my brain, emerging to embarrass me on this future date.
It is even scarier. It occurs if the number of lines of code someone produced spans across several lines. And if you want nightmares, extrapolate LoC and LoLoC into LoLoLoC. shivers
The core app for the company I work for (a FORTE UDS piece of legacy code called OSIRIS) has similar strings embedded in the database, for things such as determining the user's profile (why make a lot of columns when you can have one column represent a lot of values). It's obscure as hell.
This post reminded me I need to find alternatives soon - though it's hard to quit because the company I work for pays slightly above average wages for my country and has job security.
Recently I found this link which was an attempt to justify TDD/BDD methods to program something then to unfactor it and make it significantly more complex. Not as awesome as the TDWTF post though.
There was a company I worked for, that is very very large, that was coming out with "new technology" that had hundreds of thousands of lines of C code just like this.
Most of the code was approximately 20 years old. The original architects are probably dead.
And so was that project in about a year and a half... so I quit. I'm much happier now.
I work for a company were a predecessor made this kind of terrible code. Nobody can understand how it works. And as the product works, most people say: "He was a Genius".
But the amusing part is the was proposed a full job and he refused it for a better paid one.
Until now, it is a bit miraculous he's product didn't exploded while trying to maintain it. And each time I propose to rewrite some part, it is refused because it seems too _risky_ to touch this code.
The worst is everybody is aware of the fact that this code cost very much. But nobody want to (or can) pay a bit extra immediately to redo the complete project with "clearly" some new bug that will certainly appear.
I would love to see the execution plan for that Regex-heavy SQL query. I'll send it to our DBA if he's ever having a bad day and needs a reminder of how bad things can be elsewhere ;)
Actually, I think many DBAs would love a problem like this, because there is soo much room for optimization. You could make this thing run much faster.
Of course, then you'd just be making a piece of shit work faster....
Just to set the record straight, Caché -- which is the last man standing of MUMPS packages at the present day -- includes support for bitmaps.
It also contains support for everything else from AJAX to the kitchen sink, since it originates with several independent (and competing) OS/programming-language/database systems, originating in the late '60s before worse-is-better ate everyone's lunch. It even works as a RAD environment (plus a webserver, an SQL database, an OO programming language, and a go-between for other systems' incompatible message formats): very unusual (I expect the kitchen-sink module, or perhaps the mail reader, in the next version), but not primitive.
Its reputation is sullied by some WTF-worthy users, and by old coding conventions (now less completely abandoned than they should be) that were like Perl but hard to understand.
Full disclosure: I work for Intersystems, but not in Sales, and this post is purely on my own initiative. (One does not pay people to make unflattering comparisons with Perl.)
> It also contains support for everything else from AJAX to the kitchen sink ... It even works as a RAD environment (plus a webserver, an SQL database, an OO programming language, and a go-between for other systems' incompatible message formats.
Sorry but that sounds like a Frankenstein monster type of language/sdk/database. Now I am more scared of it than before ;-)
Has a company ever sued any TDWTF submitters, or is the code just too embarrassing to be associated with? I've seen a fair amount of crazy code like this in the wild, but haven't had the balls to submit, even after some obfuscation.
I'd love to see anyone's examples of code that is actually beautiful but equally ungainly/unnecssary. I've seen Ruby metaprogramming / monkey patching used in ways that are equally unmaintainable, but also fail to set off such obvious alarms.
Been there, seen that, all I got was this lousy t-shirt.
From the system I maintain:
/*
e - ExternalStatus
i - InternalStatus
e\i | D F N X
--------------------------
D | A B C D
F | E F G H
N | I J K L
X | M N O P
*/
switch( $inst->Status ) {
case 'A' : case 'D' : case 'M' :
$stats['d']++; break;
case 'E' : case 'F' : case 'G' : case 'H' :
case 'B' : case 'J' : case 'N' :
$stats['f']++; $stats['d']++; break;
default : $stats['n']++;
}
Reminds me of a client who wanted to know why the program took so long. "I mean, it's all just 1's and 0's, right? he said. I think he was serious, too!
Good old HN. It's so easy to predict what will happen to a comment like this - in this case, +1 because it's mildly witty compared to the other comments, -1 because someone feels like it shouldn't be upvoted, and another -1 because it's at the bottom or is now relatively content-free compared to the newer posts. Will probably settle around 0 or -1, depending on how long the post stays on the front page. I'd gladly take the two-point hit in order to verify my suspicions.
I'll probably get more downvotes than you for this, and maybe even a "this belongs in Reddit" type comment, but you're obviously trying to pull "Winning by losing" on us. Besides, it's not a "prediction" if you say it after the event.
Ah, my prediction was wrong. But little do you know that I predicted that my prediction would be wrong because I knew that by openly anticipating my comment's downvoting, I would prompt you to upvote it. Dance, puppets, dance! How droll. Now excuse me while I go stroke my white Persian. Mmm... exquisite...
Don't worry. I bet there are lots of HN'ers who regularly experiment and A/B test HN comments & submissions, in order to learn what yields the best karma. A bit like SEO but just for HN.
Then you will become indispensable. Managers will never know if your code is unmaintainable because software you wrote is inherently complicated or because you are an "awesome" programmer. New coders hired to maintain your codebase will admit failure quickly, or propose costly "total rewrites", so it becomes cheaper to keep you around.
Sadly, all this from experience on the receiving end. We ended up throwing away similar code and firing original developers, but we spent ungodly amounts of time at meetings first.