The Daily WTF: Curious Perversions in Information Technology

What Could Possibly Be Worse Than Failure?

by Alex Papadimoulis in Alex's Soapbox on 2007-02-28

Earlier this week, I changed the name of the site to Worse Than Failure. A lot of readers weren’t too happy with the new name and many of you wondered why, of all names, did I choose Worse Than Failure. After all, what could possibly be worse than failure? In lieu of telling a specific story of failure today, I’d like to share my insights as to why there are – and will continue to be – so many spectacular WTFs (as in, for old time’s sake, What-The-F*s) in our industry, and why so many of them are, in fact, worse than failure.

In the almost-three years that I’ve been writing this blog, I have seen some of the most obscene perversions in information technology ever created. Heck, we all have. While quite a number of these disasters can be blamed on amateurish incompetence, so many defy all explanation. It’s as if highly-capable, incredibly-intelligent, and good-natured software engineers got together and said, "Let’s build the worst software ever created!"

119 comments - Last comment @ 2025-11-05

Impossible, Impractical, and Too Expensive

by Alex Papadimoulis in Feature Articles on 2007-02-26

A. Thompson didn’t realize it at the time, but he had taken a job as a Third-Class Programmer. For those unfamiliar with this class, those in it are considered to be even lower than Contractors (i.e., the second-class). They have far less responsibilities, no latitude to make any decision at any level, and always get assigned the “dirty work.” In fact, some even consider it an act of charity to call these poor folks “programmers” at all.

A.’s new job was at a company I’ll call Herald Media Services. At the time, they were the largest (in fact, one of the only) suppliers of cable television listing data. Although Herald did all sorts of interesting things with this information, A’s department focused entirely on “new headend setup.” They didn’t do any of the fun stuff like configuring headend equipment; they simply had to generate a pipe-delimited information file containing locale-specific channel information. And as Third-Class Programmers, they had to generate this file by hand.

103 comments - Last comment @ 2009-03-24

Announcement: Free Sticker Week!

by Alex Papadimoulis in Feature Articles on 2007-02-26

The bad news is that, judging by recent comments, everyone has stopped reading since I changed our name to "Worse Than Failure." The good news is that I’m giving out free stickers to the dozen or so of you that decided to stick around! Simply be one of the first hundred to fill out this form and I'll mail you a sticker for free. Don’t worry if you miss today’s; I'll be giving out a hundred each day (UPDATE: Starting at Noon, EST) through Friday this week. Enjoy.

Well, that was fun! A lucky 668 of you managed to fill out the form and will be sent a free sticker. As for everyone else, you can still get one, you'll just have to cover the postage. Details Here.

133 comments - Last comment @ 2024-10-08

Announcement: Website.RenameTo(“Worse Than Failure”)

by Alex Papadimoulis in Feature Articles on 2007-02-24

Final Update: thankfully this is all nothing but an embarrassing memory.

As you can probably tell by now, The Daily WTF is now named Worse Than Failure. Don’t worry – nothing else is changing – it’s still the same ole’ WTF.

425 comments - Last comment @ 2011-09-28

GRG and the Mystery of the High Test Scores

by Alex Papadimoulis in Feature Articles on 2007-02-22

One thing I miss about working at a large organization is watching the blame game get played out. It always amazed me how much more effort went into explaining why a problem wasn’t someone’s fault (and most certainly not his responsibility to solve) than actually solving the problem itself. The larger the issue got and the more experienced players that got involved, the chance of actually solving the problem became nil.

At a certain government agency -- whom I'll call them the National Intelligence Bureau -- several different agents had been involved in a few “high profile” incidents of the international variety. This resulted in a public outcry and strict orders from the top to rectify the problem. As an IT contractor working for the NIB, G.R.G. had a chance to watch the whole thing play out from the inside.

55 comments - Last comment @ 2008-05-01

Immaculate Backup

by Alex Papadimoulis in Feature Articles on 2007-02-21

Murphy's Law 198§44: the more complete a backup/recovery solution becomes, the less likely it is to ever be used.

With nearly half a century of experience using computers to run their business, Chris M's company knew that law all too well. Ever since that fateful Wednesday -- still known throughout the company as The Crash of ‘68 -- they swore, Never Again. And forty years later, they’ve kept their promise.

59 comments - Last comment @ 2010-10-21

Bunker Buster

by Alex Papadimoulis in Feature Articles on 2007-02-19

“Hope I’m not waking ya up, but we need a huge favor.” It was just past dawn on a Saturday morning, and Jack’s new boss was on the line. “We need you to replace some servers for the portal system.”

Earlier that week, Jack started working as a subcontractor to maintain and “fix up” a certain government agency’s web portal that was used by thousands of branch offices around the country. Jack’s boss, a tech-savvy businessman who had mostly setup the web portal by himself, was training users and demonstrating the product, and noticed they had a serious problem: their system was running ridiculously slow.

114 comments - Last comment @ 2024-07-08

A Case of the MUMPS

by Alex Papadimoulis in Feature Articles on 2007-02-13

You may not realize it, but the majority of us developers have been living a sheltered professional life. Sure, we’ve got that living disaster of a C++ application and that ridiculous interface between PHP and COBOL written by the boss, but I can assure you, that all pales in comparison to what many, less fortunate programmers have to work with each day. These programmers remain mostly forgotten, toiling away at a dead-end career maintaining ancient information systems whose ridiculously shoddy architecture is surpassed only by the tools used to create it. Bryan H lived in such a world for over two years. Specifically, he worked at a “MUMPS shop.”

With no experience and a three-week old college diploma, Bryan was pretty happy to land his first programming job. He had never heard of the programming language that the company used, but he was assured that he’d receive plenty of training and should have trouble picking it up. And they weren’t joking about “plenty of training.” Bryan’s first three months were spent entirely in a classroom filled with other recent grads, all learning about what the next forty years of their lives had in store: MUMPS, MUMPS, more MUMPS, and, if they were extra lucky, a dash of Visual Basic.

380 comments - Last comment @ 2024-05-30

Practice Makes Perfect

by Alex Papadimoulis in Feature Articles on 2007-02-12

Most of us IT professionals have come to learn just how cautious one must be when upgrading third-party components. Some of us have learned the hard way, first proclaiming, pssh, big deal, it's just Service Pack 3; it couldn't possibly break our application, and then learning that, in fact, Service Pack 3 was a big deal and did break the application. Others are naturally cautious and try to make sure planning, testing, and all those other things are done prior to any upgrades.

Database upgrades can be especially risky. A new version means different query optimization, new language constructs, and, in Oracle's case, the introduction of VARCHAR3 and subsequent deprecation of VARCHAR2. This is why, when Kevin's company decided to upgrade their database from SQL Server 2000 to SQL Server 2005, they put him in charge of formulating a schedule for a six-to-twelve month upgrade plan.

109 comments - Last comment @ 2008-03-19

The Accidental Hire

by Alex Papadimoulis in Feature Articles on 2007-02-08

Doghouse Insurance (as we'll call them) was not a pleasant place to work. Despite being a very successful player in their industry, the atmosphere inside Doghouse was filled with a constant, frenzied panic. If Joe Developer didn't delay his upcoming vacation and put in those weekend hours, he might risk the timely delivery of his team's module, which might risk delaying the entire project, which might risk the company's earnings potential, which might risk the collapse of the global economy. And that's just for the Employee Password Change Webpage project; I can't even begin to fathom the overarching devastation that would ensue from a delayed critical project.

To make matters worse, the primary business application that poor souls like Vinny maintained was a complete nightmare. It was developed during the company's "database simplification" era and consisted of hundreds of different "virtual attribute tables" stuffed into four real tables; it was a classic case of The Inner-Platform Effect. But amidst all this gloom and despair was an upbeat fellow named Chris who accidentally became a part of the Doghouse Insurance team.

95 comments - Last comment @ 2007-02-14

Twelve on a Line

by Alex Papadimoulis in CodeSOD on 2007-02-01

GRG writes: I've been trying to track down an error in a certain program, used by hundreds of people around the world every day to process gigabytes of very important data. Sometimes it works "fine", other times, not often, only about 0.41% off the time, it goofs up the data, from minor-league (0.22%) to big-time (80%). Apparently the users of this data are not very careful, as the program has had these bugs for at least six years.

It took quite a few days to track down the problem, as the program, for no good reason, resides in about 188 separate FORTRAN and C source files. Finally I found the source of the glitch. Let's see if you can spot the problem too.

163 comments - Last comment @ 2012-05-22