The Daily WTF: Curious Perversions in Information Technology

Remotely Incompetent

by Scott Selikoff in Feature Articles on 2011-11-08

"Welcome back, Susan!" one of Susan’s co-workers said as she walked in the door. As she strolled to her desk, the co-worker continued, "Hope you enjoyed your vacation. You missed quite a fireworks show while you were away. We lost an entire day’s worth of orders, bit of a nightmare."

Susan had spent last week at sunny resort with her family, and was trying to adjust back to the cold January mornings in Massachusetts. Being greeted with the news that their ordering system had been offline for almost a day was not something she wanted to hear.

219 comments - Last comment @ 2011-12-27

The Tell-Tale Cable

by Scott Selikoff in Feature Articles on 2011-07-26

As an experienced IT professional, Drew had seen his fair share of network outages over the years. He had protected his company’s network from storms, earthquakes, and even floods, but more often than not, the problem was from within. His fellow coworkers found ways to bring down their computers far more frequently on their own, through a combination of sending virus-laden e-mails, unplugging cords, and in some cases just gross incompetence.

One afternoon, Drew was installing some software from the network onto an employee's computer when the system locked up for 10 seconds.

158 comments - Last comment @ 2011-08-02

Six Weeks Steve

by Scott Selikoff in Feature Articles on 2011-01-25

Gary was sitting at the local café, enjoying his morning coffee and a muffin. He was taking a well-deserved break following a release of his new client’s software the day before when he spotted his old manager Steve walking toward him.

"Gary!" Steve shouted. "I was just about to give you a call!"

134 comments - Last comment @ 2024-08-12

The Unmanaged Stock Management System

by Scott Selikoff in Feature Articles on 2010-12-01

In the world of software consulting, there are many ways in which software is delivered to the client. Sometimes, a consulting company may choose to sell the software to the client, providing both the working application and the source since (most of the time) the software is so customized to the client’s need, the consulting company does not have much reason for keeping the source code to themselves. In other situations, though, consulting companies may choose to license the software to the client, with regular patches and bug fixes, while retaining all ownership.

Paul was working as a freelance coder, fresh out of college, when he accidentally stumbled upon a third option: give the source code to the client, but obfuscate the software to such a degree that any developer who tried to work on it would go mad.

169 comments - Last comment @ 2012-01-12

Swallowed by the Beast

by Scott Selikoff in CodeSOD on 2010-08-23

Paul was having a good morning. It was a beautiful day outside, he managed to shave 15 minutes off his commute, and even the local coffee shop had his favorite donut in stock. All of that changed when he got his first support call of the day. It was from a client running "the beast" product. "The beast", as Paul and his coworkers nicknamed it, was a legacy version of their application developed somewhere overseas years before Paul was hired, by hundreds of poorly trained, and probably poorly paid, developers. The company's sales team actively encouraged clients to upgrade from the legacy application, but a select few had resisted.

"The beast" had a reputation for containing some of the worst code Paul had ever seen and every time he had to support it, he felt like he needed a shower afterwards. It was during his fourth hour of debugging that Paul came across a previously unvisited function shown below.

110 comments - Last comment @ 2011-09-05

The Tim Problem

by Scott Selikoff in Feature Articles on 2010-07-27

While many developers sit behind a desk, only seeing the sun on their way to and from the parking lot, Mike felt lucky that he got to travel all around the country performing installations of his company's enterprise software. He enjoyed seeing new places, exploring the local nightlife, and most importantly for a business traveler, expensing everything to a corporate account.

Having installed the software hundreds of times and in dozens of cities, the process had become routine for Mike. He'd send the client's IT administrator a list of requirements, verify that he'd have the appropriate access, and when he'd arrive on-site, spend an hour or two configuring the software. His job after that was to monitor training classes given by a coworker he traveled with, while brushing up on his Freecell.

Something Different

114 comments - Last comment @ 2023-08-08

That's One Way to Fulfill a Requirement

by Scott Selikoff in CodeSOD on 2010-06-21

Everyone responds to new requirements on already-behind-schedule projects in a different way. Many people feel anger, and try to find an innocuous way to show it. Others, realizing this might finally be their chance to shine, take it as a challenge with a smile. Still others, like Gary's colleague Steve, find a way to fulfill the requirements without actually fulfilling the requirements.

With less than a week remaining till the deadline of a 4-month-long project, Gary and Steve's boss demanded everyone write Unit test code. Gary spent hour upon unpaid overtime hour adding as many unit tests as he could come up with, while Steve left by 5pm each day. Their boss also asked them to set up a nightly script to perform the unit tests automatically. Each night Steve's test set would always come back with 100% successful results.

101 comments - Last comment @ 2010-06-26

On the Job Training

by Scott Selikoff in Feature Articles on 2010-06-15

"None of our customers' web servers are online!" was not the kind of thing Ryan wanted to hear in the morning. Nor was it the kind of question Ryan wanted to hear from the 15 different department heads and administrators all shouting on the conference call that morning. Luckily (for everyone but Ryan), Ted from Net Operations was on the call. Ted was one of those hands-off system administrators who found that it was far easier to delegate work to someone else and leave early for a bar.

After 10 minutes of bickering, Ted announced that he had found the root cause of the problem: Ryan. He announced to the group that Ryan, in his ignorance and naivety, had deleted all of the customers' web servers from production. In shocked realization that today might be his last day on the job, Ryan was unable to speak at first, but one detail gnawed at him - throughout it all, he had followed the steps that Ted had given him to the letter. Ryan needed answers - if Ted said that he did indeed wreck the Production environment then it was Ted who would show him.

The Training Process

81 comments - Last comment @ 2024-02-23