The Daily WTF

Error'd: Where Does the Line End?

Jake Vinson — Fri, 09 May 2008 12:00:00 GMT

Jacob S. apparently wandered away from the line and wasn't even in the right city anymore.

Serg K. made Visual Studio get all confused and disoriented.

Justin S. is too savvy a customer to fall for this:

Similarly, Lukas M. didn't get roped into this shady deal:

I don't really follow golf, but man, I can't believe I hadn't heard of Mike Weir's amazing game at Pebble Beach. Consider me and Nils H. impressed!

"Imagine my surprise when I saw the news this morning that the minimum wage was increased," wrote E. J. Gonzales. "It's nice to know that Osama and the rest of Al-Qaida are so concerned about the average working citizen!"

Colin S. can think of at least one problem with dispensing $0.00 bills.

As a huge Formula One fan, David W. jumped at the chance to purchase one of his favorite drivers.

Brought to you by the Non-WTF Job Board:

Two Weeks Notice

Jake Vinson — Thu, 08 May 2008 14:00:00 GMT

"Welcome aboard, Colin!" Colin M. gave his boss a firm handshake, excited about his first day on the job. He'd be a member of the team that worked on an application that ran on a managed information appliance. "I'll set you up with Mike, who can show you the ropes."

Colin's boss turned him over to Mike, who started describing the system architecture immediately. "So here's what we've got," he began. "The core is the email processing module. It takes in an email, logs a little information, and stores attachments in the file system. Easy, right?" Mike gave him a little more background, but reasoned that Colin should be able to figure it out.

It sounded so simple that Colin could hardly imagine any reason that they had more than one developer actively supporting the application. That is, until he saw the architecture (to use the term loosely). Try to follow along:

The core of the application was a system which processed items of incoming email, logging some information to a database and storing attachments in the file system. A Perl web-app controlled the behavior of the system and allowed access to the results. Of course, the system had to interact with Microsoft Exchange servers, since that's where most of the clients stored their email. It also had to interact with various third-party products which were Windows-only. So, naturally, as a host operating system for their appliance, they chose Linux. The web application would run natively under Apache, with the rest of the sytem running inside a virtual Windows XP host in VMWare. The two would communicate via HTTP, with the Linux host invoking a mixture of Perl and VB scripts under IIS on the XP guest to communicate with the Windows components.

I tried to represent this with a flow chart, but did an embarrassingly terrible job of it and wasn't going to include it with the article. Then after thinking about it some more I realized that the quality of the flow chart is a good metaphor for the quality of the process. Generally, the squiggly lines represent HTTP requests and my own ineptitude with Visio.

Because the application had to work with Exchange servers, it would stand to reason that they would design the interface using the Exchange SDK. Instead, the system required an instance of Outlook running on the virtual XP machine to move the emails around. Colin discovered this on his third day when he got an call from an upset client that their system was hanging. He had to solve the problem with the following process:

SSH to the customer's Linux host
Open a port to allow VNC or Remote Desktop access
Connect via VNC or Remote Desktop
Click 'OK' on whatever dialog in Outlook was awaiting a response

The Perl-based management web application had four routines in it, which represented over 70,000 lines of code. That count includes comments, but only because there weren't any. Most of it was un-indented and had been copied and pasted from sources unknown.

The lead developer was notoriously cagey, and meticulous about his code. So much so that he wanted to keep his code a secret from everybody. After all, if he checked his code in to source control, that would mean that other developers could *gasp* see it, and perhaps *double gasp* maintain it. So instead of code, he'd check in compiled assemblies.

Colin butted heads with the lead developer near the end of his first week about a scheme he'd developed for passing hierarchical data in Perl, using a jumble of arrays of values prefixed with period-delimted path names. Colin's suggestion that it might be easier to store the hierarchy directly using hashrefs was met with a five-second blank stare, then a suspicious and dismissive "that sounds very clever," before he returned to his explanation.

Before he'd even finished his first two weeks, Colin knew that he had to move on. Since Colin had interviewed with the CTO, he intended to catch up with him to discuss his plans. That morning when Colin came in, he discovered that the CTO had gone on safari, but he hadn't gotten around to telling anyone he'd be gone or where he was going. Instead, Colin sent an email to him, CCing his immediate boss with his intention to leave in two weeks. Trying to be as polite as possible, he explained the circumstances he had worked under, and appologized for needing to quit so soon. Colin tried to keep the tone pleasant and professional to avoid angering the CTO. It didn't work.

In a heated response, without even the slightest hint of the irony of it, the CTO scolded Colin by saying that his level of professionalism was barely suitable for a position at McDonald's, and that he should "just leave right away."

After that, Colin had to fight with HR and the CTO for several months to squeeze a paycheck out of the company for his few weeks of service. When they finally agreed to pay, the CTO gave Colin two options. 1) Pick up the check in person, get yelled at by the CTO. 2) Receive check by regular, un-trackable mail (as long as Colin signed a statement releasing the company from any responsibility if the check mysteriously didn't turn up at his house).

Colin chose the former.

Brought to you by the Non-WTF Job Board:

Representative Line: Very Specific Generics

Alex Papadimoulis — Thu, 08 May 2008 12:00:00 GMT

"I'm as much a fan of Java Generics as the next guy," writes Jim Bethancourt, "why bother with writing all that type-specific code for common collections (or - gasp - losing type safety) when one can simply go HashMap<String, SomeObject>."

"However, after working on several of my predecessor's projects, I think it's pretty clear that liked generics, too. But I'm gonna go ahead and say that he liked them juuuuuust a bit too much. This was one of way-too-many lines in the variable definition section of some (you guessed it) generic class...

HashMap<Long, HashMap<Timestamp, Vector<HashMap<String, Object>>>> superHashMap =
    new HashMap<Long, HashMap<Timestamp, Vector<HashMap<String, Object>>>>();

Brought to you by the Non-WTF Job Board:

Tales from the Interview: Let's All Reinvent the Wheel... Again, and More

Alex Papadimoulis — Wed, 07 May 2008 14:00:00 GMT

Let's All Reinvent the Wheel... Again (from K.D.)

I was interviewing candidates for a junior web application development position. The candidate had, so far, seemed very knowledgeable and more than met the requirements of the position. I had, in fact, almost made my decision that I would make Joe an offer, but I had to ask just one more question.

I'm a big believer in wide-ranging open-ended interview questions in an interview, because they make the candidate think AND talk, and can often reveal insights into their personality or work styles. I asked the candidate, "we've all had projects we've worked on that didn't go exactly as we might have liked, for any number of reasons. Maybe the project got pressured to finish early and you had to rush your work, for example. Or maybe technology has changed since, giving you a much better way to complete a task, or you've learned a different way to accomplish the task. Tell me about a project that, in hindsight, you wish you could go back and re-work, and why?"

This question has been very helpful for me in interviews. I learn about the candidate's humility, or lack thereof, as well as provide an opportunity for them to perhaps highlight some thinking process of theirs that they feel I haven't yet witnessed, or to talk about something they learned, or to brag on how they continually read and research into new technologies. It once again did not disappoint me.

I have never had an opinion on a candidate reverse itself so completely and quickly. Joe first won the humility points by saying "No, no, never, when I finish a project, I know I've done it right. It's done the best way possible!" (wouldn't we ALL love to work with this person on a team project?) and then dug his grave even further by telling me "besides, I couldn't go back and rework a project anyway. As soon as I've finished and installed the application, I delete the code. I like to start every project with a clean slate, I don't believe in copying from what I did previously. I just start it over brand-new!"

Great Receptionist Resume... (originally posted to the SideBar by "AustinW")

This is from an actual resume that we got for a Receptionist position...

Lowering Standards (from Eyal & Hila)

The company I work at takes the search for new employees very seriously. We pride ourselves on having immensely high standards. For example, the last position that had to be filled on the C++ server team took literally months and several dozen interviews to fill. So when a developer left, no one was looking forward to starting a round of interviews again.

All new interviewees are first given a written test for basic C++ competence, that includes such questions as "What are const member functions?" or "What is wrong with the following code sample?"

Once a person has answered reasonably some of the questions and managed to have an intelligent conversation about those he did not answer with whoever is going over the test with him, he is sent up to higher management for an actual interview.

I was sent in to go over the test with a person who shall remain nameless. She was greeted by my boss, given the test, and left alone for the mandatory half hour. I went in to see her without having a chance to look at her resume, so I just went straight at it.

The first third or so of the test was relatively uneventful. She managed to define some of the basic terms, and get the trick questions wrong, as did most people.

Next was the most informative question of the test: pointing out and correcting the myriad of flaws in a short program. The most obvious of which is a function receiving a string parameter by value and non-const, so it was no surprise that she had circled "std::string", a standard library string object, probably to note that it should be passed as a const reference.

"What's this?" I asked her when we got to talking about her changes, hoping for the first intelligent answer of the interview.

"Oh, that..." she said, "I didn't know what this 'std' means."

"I see," I said, and ended the interview immediately.

Brought to you by the Non-WTF Job Board:

Error'd: Worst. Preview. Ever.

Alex Papadimoulis — Wed, 07 May 2008 12:00:00 GMT

"I have this feeling most of the day while I'm on support," writes M, "but I've never thought to try telling people."

"I was at the theaters in Lake Forest, Orange County, watching some previews," Kamran Kazempour said, "and this came up on the screen for a minute or so before the feature. "

While Jeremy wasn't quite sure how an email address could fit in only four characters, he was a bit dismayed that his was too long to register...

"Apparently, computers are not all that good with math" Brent Rockwood wrote, "iRobot thinks they need a little help with this age range calculation."

Brought to you by the Non-WTF Job Board:

The Webcam DoS Attack

Jake Vinson — Tue, 06 May 2008 14:00:00 GMT

Where are my keys? Cam S. had checked under every couch cushion, in every jacket pocket, under every bed, everywhere for his keys. While checking the kitchen counter for the third time, he glanced at the oven clock. 8:35. Even if the skies had opened up right that minute and his keys descended on a golden platter, he'd still be at least ten minutes late for work.

It was then that he peeked in the garage and beheld a beautiful sight — his keys sitting on the drivers' seat of his truck. If he drove unreasonably, dangerously fast, he might still be able to get to work on time! Cam breathed a sigh of relief when he saw the keys in his truck. His locked truck. Damn it! The only other key was with his wife, who had left for work a while ago. It was clear that it just wasn't in the stars for Cam to go to work that day.

Oh well, there was a silver lining. Working from home means no commute, no finding a parking spot, no changing out of your favorite robot PJs, no not watching Judge Judy and eating Doritos all day — pretty much exactly how the Bible describes heaven.

Cam fired off an email to his boss, "Joel," to let him know that he wouldn't be in that day. Immediately, an out-of-office autoreply came back, so per bank policy, Cam had to email Joel's boss, "Ron," with all of Joel's team CC'd with contact information. Minutes later, a smartass on Cam's team replied-to-all with a snarky "Yeah, whatever, Cam. We all know that by 'working at home' you mean you'll be sitting on your couch in your PJs eating Doritos and watching Judge Judy." It's like he's psychic! Cam thought. Still, he could prove them wrong with his new hobby project — a periodically updating webcam image on his personal web site. Just as soon as he changed out of his PJs and moved the Doritos out of the shot.

It was a pretty crappy webcam — its maximum (and only) resolution was 320x240 with a color palette that rivaled EGA. Fortunately, this resulted in small file sizes (~17kb per image), and since he was hosting the site out of his basement, every little bit of compression helped. Cam fought reply-all with reply-all, opening with "Nuh-uh," and choosing his words carefully to avoid an escalating "yeah-huh!" "nuh-uh!" quagmire: "I'll prove it! Here's a link to my personal web site!"

Rather than continuing in the webcam site direction by adding eighth grade-level poetry, "which Backstreet Boy are you" quiz results, and PayPal donation buttons, he did the unthinkable — actually worked from home. And he managed to get a lot done; answering emails, chipping away at some bug fixes, preparing reports (all the while remembering not to pick his nose on camera).

During a quick lunch break, Cam got a panicked call from his boss's boss, Ron. "Cam, do you still have your webcam on?"

"Yeah, wh-"

"Turn it off. NOW," he said in all caps over the phone.

"Uh, ok." Cam flicked the switch on the webcam off. "So, why exactly is it so urgen-"

"Can'ttalknowbigproblems-" *click*

That was weird, Cam said as he checked his pants fly and the section of the room that was in the shot. Finding nothing that could have upset anyone in the last few snapshots, he shrugged it off and got back to work.

It was then that Cam learned about one negative side-effect of working from home — being the guy that gets to work from home. There's a perception that the work-from-home guy's life is so much better than yours, that they do jack squat all day, and get paid more for it. True or not, it makes people jealous, and jealousy breeds contempt. Contempt breeds blaming. Blaming breeds repercussions for Cam.

See, it seems that there was a brief but major hiccup in a router somewhere between the bank's data center and their T3 provider, causing a dramatic slowdown in outbound network performance, which rippled out into hundreds of branches and affecting thousands of online banking customers. In the troubleshooting process, the lead network engineer caught wind that Cam had been "streaming live video" over the network, and was going to tell! He complained loudly to Ron that Cam had caused the issues and lost some revenues for the bank in the process. Adding to this theory was the fact that the issue had apparently resolved itself close to the time that Cam turned off his webcam.

One week later, Cam is sitting with his boss Joel to discuss the issue. "Cam, I'm going to need you to sign this disciplinary action report before we file it with HR," Joel said weakly.

Appealing to reason, Cam began, "Joel, you know exactly what happened. You know that all that was coming across the network was a static web page with a new image every so often. I never had more than five HTTP sessions at a time. It would take thousands, if not hundreds of thousands of simultaneous users accessing my web site at the same time to consume the bandwidth that it says I consumed on this report."

"I know," he said as his expression sank. Clearly, he'd fought for Cam and been overruled.

"Besides that," Cam continued, "I'm hosting my site at my house. My upstream connection is capped at 360 kbps. There's literally no physical way that anything I did from my house could even make a dent in our massive T3 lines, even if my upstream connection was 100% saturated!"

"I know," Joel said as his face slipped into his hands. At this point, it dawned on Cam that he was lucky that all that was happening to him was a writeup. It sounded as though upper management would prefer to see him hanged. Still, it was absolutely unfair that he'd be made to take the fall.

"Furthermore," Cam pressed, "what about our QoS policies? Surely internal users browsing external web sites have lower priority than-"

"I know," Joel said again. "Look, I've fought them on this. You know I trust you, and that I know you wouldn't ever — that you couldn't ever — do something like this. I'm saying this as a friend; you're better off just signing this. It's not just you; management is pissed at me now, too. It's not fair, but it's how it is."

In the end, there wasn't much Cam could have done. Joel had backed him up and explained the inescapable facts that Cam couldn't have caused the network issues even if he'd tried. Cam signed the form and spent several more years at the bank, eventually rising to the rank of Lead Developer. And the network engineer that had pinned the issues on Cam even learned to respect him as a colleague (though they never spoke of the incident).

Today, even though he'd left the bank for other opportunities, he and Joel occasionally share a laugh over the $30 webcam that brought down the bank's network.

Brought to you by the Non-WTF Job Board:

CodeSOD: A Rather Minor Change

Alex Papadimoulis — Tue, 06 May 2008 12:00:00 GMT

"Not too long ago," Jess writes, "I adopted an application that needed 'a rather minor change' to its functionality. Naturally, when I started, the project owner had no idea what file or directory the functionality was in, so he gave me access to the server and sent me off. After wading through a number of oddly named directories trying to find where the site was even located, I finally found the index file I had hoped would set me in the right direction."

"Of course, it didn't. After twenty minutes of jumping from page to page to page, I realized that I'd simply have to grep the entire application: a gig or so of content with tens of thousands of files within hundreds of directories. After nothing turned up, I quickly realized that most of the files had completely meaningless extensions: .html files had lots of PHP, .php4 files had PHP5, and .php files rarely had any PHP.

"After expanding my search, I noticed a curious directory named "google". It was packed with files like this:

cache_results.php        engines_2.php            engines--.php  
googlesearch.inc.php     index.php                ORIGINALengines.php
engines_old.php          engines-.php             g_original.php 
my_search_results.inc    query.php                search_results.inc.php
engines_2007-05-01.php   -engines-.php            engines.php
index.html               search.html              test.php

"Upon closer inspection, I discovered that nearly all of the similarly named files had nearly identical content, and were all referenced throughout the other files in various directories, all which may or may not have been used in the site. Oh, and they all looked like this...

<?php
class GoogleSearch
{ var $url; var $lang;
  var $cookie; var $query;
  var $rpp; var $ra; var $rb;
  var $results; var $referer;
  var $nresults;

  function GoogleSearch()
  { $this->url='http://www.google.com/'; $this->lang='en'; $this->rpp=100;
    $this->ra=0; $this->rb=0; $this->query=''; $this->nresults=0;
    $html=Browser($this->url); $this->cookie=GetCookies($html); }

  function GoogleQuery($q,$n=1)
  { if (!($q==$this->query && $n>=$this->ra && $n<=$this->rb))
    { $u=$this->url.'search?q='.urlencode($q)."&num=".$this->rpp."&hl=".$this->lang."&lr=&safe=off&sa=N";
      $this->ra=(($n-1)-($n-1)%$this->rpp)+1; $this->rb=$this->ra+$this->rpp-1;
      if ($n>$this->rpp) $u.='&start='.($this->ra-1);
      $this->query=$q; $html=Browser($u,'GET','',$this->cookie,$this->referer); $this->referer=$u;
      $this->results=array();
      $p=0; do { $p=strpos($html,'<p class=g>',$p);
                 if ($p!==false)
                 { $r=array();
                   $a=strpos($html,'"',$p+11)+1; $b=strpos($html,'"',$a);
                   $u=substr($html,$a,$b-$a);
                   if (substr($u,0,4)==='/url') $u=substr($u,strpos($u,'&q=')+3);
                   $r['url']=$u;
                   $a=strpos($html,'>',$b)+1; $b=strpos($html,'</a',$a); $p=$b;
                   $r['meta']=strip_tags(substr($html,$a,$b-$a));
                   $a=strpos($html,'<font',$b); $b=strpos($html,'Similar pages',$a);
                   $u=substr($html,$a,$b-$a); $b=strpos($u,'color=#008000>');
                   if ($b!==false)
                    $r['content']=trim(strip_tags(strtr(substr($u,0,$b+14),array("<br>"=>" "))));
                   else $r['content']='';
                   $this->results[]=$r; }
               } while ($p!==false);
    $a=strpos($html,'of about <b>');
    if ($a!==false)
    { $a+=12; $b=strpos($html,'</b',$a);
      $this->nresults=strtr(substr($html,$a,$b-$a),array(','=>'','.'=>'')); }
    else $this->nresults=0; }
    $u=$this->results[$n-$this->ra];
    return $u; }

  function ResultsNumber() { return $this->nresults; }
}
?>

"Yeah, this code has it all: not a single comment, variable names between 1 and 3 letters long, almost no formatting, and a whole bunch of statements packed into a single line. I won't even go into all the actual problems with the code.

"As for what this file does... how it's being used... if it's being used... I still have absolutely no idea. But the good news is, I've learned my lesson about projects needing only 'a rather minor change'.

Brought to you by the Non-WTF Job Board:

Best of the Sidebar: Code examples and interviews

Jake Vinson — Mon, 05 May 2008 14:00:00 GMT

Tsk, tsk. After all the requests to plz email me teh codez, and the Daily WTF community's failure to recognize student initiative, "MonkeyCode" posted a similar story in the sidebar...

We're looking for some new developers on our team here at our online travel reservation startup. London being London at the moment, it's proving hard to get good quality candidates to actually show up for an interview. Little did we know how bad the quality can be at times.

We have a coding test that we give to potential hires. Not terribly hard, it's just a simple string manipulation exercise: Given a string, find all occurences of a substring without using any in built string functions. Obviously you'd never do this in real life, but your run of the mill Teach Yourself C# in 24 Hours developer could probably give it a shot and fool us.

It does however, weed out a suprisingly large number of people — either their code doesn't compile, it doesn't work, or somtimes they just don't read the instructions and submit finger paintings instead.

The other day, a "friend" of one of our workmates pointed out the question had been posted to the MSDN forums.

This is technically not a WTF — posting to forums can be a valuable source of information. Proving how clueless you are in a public forums, however, is.

There are a couple of classic responses in there, none really good enough for our potential hire, so he had a follow up post the next day asking for more help on the problem.

Being the masochists that we are, we couldn't help but look up some of our potential hire's other questions and found this beauty:

So many WTFs, so little time!

Plz post teh codes in the comments.

Brought to you by the Non-WTF Job Board:

Error'd: Please yo-yo the rrm

Alex Papadimoulis — Mon, 05 May 2008 12:00:00 GMT

"Ummm," Matt wrote, "if you say so..."

Paul S. snapped this at a Hong Kong subway station...

"I saw this diversion sign on my way to the station in Colchester, England this morning," James Mott mentioned, "I'm just glad I was getting the train."

"The most important philosophical question of our time," noted Jason L. H., "was at the 34th St/Herald Sq. subway station in New York City."

"Passenger.exe crashed repeatedly while I was attempting to view a map," writes Eric F., "but I am glad that the video screen still reminded me about the focus on improving my taxi experience."

Brought to you by the Non-WTF Job Board:

Best of the Sidebar: The Problem Child

Alex Papadimoulis — Fri, 02 May 2008 13:00:00 GMT

Originally posted by "DrillSgtK"...

In the late 90’s, I worked for a small, “start-up/spin-off” dot com company. We were originally The University’s distant learning department, but had been re-constituted as a for-profit company, owned by The University to service The University. A year and a half old, the company had grown from six people working out of a trailer on campus to a seventy-five person operation with three offices and large co-location site in a data center. The IT staff, however, remained the same size: three of us.

The sales department consisted of three people and was located five hours away in New York City. One of the salespersons – let’s call him “Michael” – was a “problem child.” Every computer that Michael touched became infected, corrupted, or had some other random problem that likely resulted from deleting anti-virus software and visiting porn sites. I should note that Michael, who also happened to be the CEO’s neighbor, demanded admin privileges on whichever computer he used. And the CEO always concurred.

A year and three whole sales later, the CEO was “resigned” and a new CEO was appointed by The University. One of the first things he did was appointing a CTO (“Brian”). And then he added a new salesperson (“Jeff”).

“I’ve got a big issue,” Jeff said when he called the IT helpline on his second day, “I can’t get to the web site! I have a prospective sale coming in a few minutes!” A few quick questions later, and the issue was resolved. As it turned out, he had just misspelled the company name. It was an understandable new-person mistake.

The three of us in IT had a habit of answering calls on speaker phone, such that everyone in our closet-sided office could hear the question and pitch-in if needed. After hanging up, we all looked at each other and said “noob!” Brian walked in a moment later, just as the phone rang again.

I hit the speaker button and answered. It was Michael.

“I’m having the same problem as Jeff.”

“Oh,” I replied, “you’re misspelling the company name, too?”

“What? Uh,” Michael said confusedly, “no. My computer is slow. It keeps opening programs like crazy. I had to power it off.”

Programs were Michael’s word for Internet Explorer windows, Javascript pop-ups, etc. I replied, “What web pages did you visit when this started?”

“Uh,” Michael hesitantly answered, “I don’t remember. I’ll call back when it happens again. Bye!” He hung up.

One of my co-IT guys pulled up Michael’s web activity logs. There were some rather interesting URLs (most with several X’s in the title) that had access times between the login time earlier that day and the support call minutes ago.

Brian, who as watching us as we did this, was rather surprised. He asked that we open the historic activity logs, and we found lots and lots of sites with lots and lots of X’s going back four months. Brian then asked to see the number of trouble tickets we had logged for Michael.

Two weeks later, Michael was let go. Shortly thereafter, the number of trouble tickets from our the New York City office dropped by about seventy percent.

Brought to you by the Non-WTF Job Board:

The Annual Reboot

Jake Vinson — Thu, 01 May 2008 14:00:00 GMT

According to Wikipedia, caching is a method of storing a collection of data for which the time it takes to compute said data is longer than the time it takes to retrieve from the cache. Also, the concept of caching was invented by Mr. T. I suspect that last part may have been added by Wikipedia vandals, though...

One of Eli A.'s predecessors took Mr. T.'s concept and ran with it. He cached everything he could get his hands on — configuration values, event dates, phone numbers, everything. Why tax the hardware with an expensive lookup when everything's right at your fingertips in a giant, hideous blob of a cache?

Eli's predecessor's tenure didn't last terribly long; he left (or was fired, maybe) after a couple of months of adding caching to virtually every aspect of the application. One of his last changes was adding a singleton to store the current year:

public class CommonVars {
    private final static CommonVars instance = new CommonVars();
    public static CommonVars getInstance() {
        return instance;
    }
    private CommonVars() {
        currentYear = Calendar.getInstance().get(Calendar.YEAR);
    }

    ...
    public int getCurrentYear() {
        return currentYear;
    }
    ...
}

With this, Eli's predecessor was able to avoid the taxing the system with a date lookup. He missed out on some of the fun that this change caused later, though, since he hadn't stayed long enough for the year to roll over.

Every January 1, a user would report some weird problems in the system recording dates in the wrong year. The complaints came from a different user each year, because for some reason users never stuck around for more than a few months. And every year, the poor guy would take several hours tracking down someone in IT to explain the problem and have them reboot the server, then the value would be re-initialized whenever the fist new user session started.

Oh well, just 244 days until the next reboot...

Brought to you by the Non-WTF Job Board:

Error'd: 792 Octiiiiiiilion Dollars

Alex Papadimoulis — Thu, 01 May 2008 12:00:00 GMT

François captured this brief video of his answering machine bug for our first-ever video Error'd.

(or download as avi)

"When ZoomBrowser crashed with this error," Karl Vanaselja wrote, "I was tempted yell all sorts of obscenties. But then I realized I was in a message filter, and that'd be illegal to do so."

"Okay, so I realize that I went over my minutes," Sam said, "but c'mon Verizon, $792 Octillion? Whatever... I might be a little late making that payment."

"I trying to find out if my domain was blacklisted," wrote Kathy Bragg, "and spotted this in the sponsored results on Google. I decided to pass on the offer."

Ryan Doherty snapped this picture at his local Ikea.

Brought to you by the Non-WTF Job Board:

The Super Hacker

Jake Vinson — Wed, 30 Apr 2008 14:00:00 GMT

As a junior network administrator at a small local ISP, Kiefer R.'s job is pretty mundane. Aside from the occasional bandwidth problem investigating, cable laying, and spline reticulating, there's not too much excitement.

One morning, Kiefer's boss said he was going to come down for a chat, so Kiefer loaded up a bandwidth monitoring utility and pretended to be busy. "Kiefer," Mike began, "I just wanted to give you a heads up. We're having a guy come down next week to run some security checks on our systems here. Particularly our main web server."

"So, you need me to show him the ropes, or..."

"Oh, ha!" Mike started laughing. "No, not at all. This guy is like some kind of Super Hacker!" he exclaimed while waving his hands dramatically. "More like he'll be showing you the ropes! Ha!" Kiefer rolled his eyes.

The Super Hacker arrived the following week. He was there only for two days while he worked on his mission — shutting down the main web server from outside the network. He'd be in the office from 9-5, where he could talk to the staff and review some of the code to find sections he might be able to exploit, but he'd only get paid if the server was shut down while he was not in the office. He didn't receive any usernames or passwords as the testing was meant to simulate an attack on the web site from an average hacker. Should he accomplish his goal, he'd earn $3,500.00. Working in the Super Hacker's favor was that the aging site was last updated in the late 90s, and almost certainly had pages that would be exploitable.

When Kiefer came in the following morning, his boss was stopped him on his way in.

"Well, our Super Hacker has done it! Turns out it must've been a pretty easy exploit," Mike said, "it hardly took him any time at all. Plus he's already patched it!"

Kiefer couldn't deny that he was impressed. "So how'd he do it?"

"I'm not sure — I haven't gotten his report yet. I should have it by the end of the day."

Kiefer's curiosity was palpable. He asked around for details on the exploit, but no one was talking. Clearly, some people knew what had happened and just weren't willing to tell. Finally, someone told Kiefer that the fix was in the form of a Python script, and that if he read the script, he'd see the exploit.

How the aptly-named Super Hacker had managed to shut down the system remotely and provide a fix so quickly intrigued Kiefer. After poking around the network, he finally found the Python file that contained the Super Hacker's fix:

#!usr/bin/python
# Paying someone $10 to pull a power cord for $3500
print "(C) <Name Removed> 2008."

Of course, the fix alone wouldn't prevent future attacks using that vector, but management's scolding of the night staff would.

Brought to you by the Non-WTF Job Board:

CodeSOD: Oh, XML

Alex Papadimoulis — Wed, 30 Apr 2008 12:00:00 GMT

"Having worked in the Computer industry for about twenty years now," Matt writes, "I rarely get the chance to actually write code. But I do get the joy of other people's problems landing at my feet when things go wrong."

"Not too long ago, one of our newer techies emailed me, complaining that he couldn't get load image data from a WebService created by another developer. Given that all of the XML serialization and deserialization is handed through our enterprisey library, it was only when I visted the WebService address in my browser that I was able to see the 'raw' data:

<attachments xmlns = "http://webservices..." >
  <bytes>37</bytes>
  <bytes>80</bytes>
  <bytes>68</bytes>
  <bytes>70</bytes>
  <bytes>45</bytes>
  <bytes>49</bytes>
  <bytes>46</bytes>
  <bytes>52</bytes>
  <bytes>10</bytes>
  <bytes>37</bytes>
  <bytes>-30</bytes>
  <bytes>-29</bytes>
  <bytes>-49</bytes>
  <bytes>-45</bytes>
  <bytes>10</bytes>
  <bytes>52</bytes>
  <bytes>32</bytes>
  <bytes>48</bytes>
  <bytes>32</bytes>
  <bytes>111</bytes>
  ...

"The error, for those that care, was that our code expected values in the range 0 to 255, rather than -127 to 128.

Brought to you by the Non-WTF Job Board:

Alex's Soapbox: Up or Out: Solving the IT Turnover Crisis

Alex Papadimoulis — Tue, 29 Apr 2008 16:00:00 GMT

If you’ve worked at enough companies in the IT industry, you’ve probably noticed that the most talented software developers tend to not stick around at one place for too long. The least talented folks, on the other hand, entrench themselves deep within the organization, often building beachheads of bad code that no sane developer would dare go near, all the while ensuring their own job security and screwing up just enough times not to get fired.

Earlier this month, Bruce F. Webster aptly named this phenomenon the Dead Sea Effect. Today, I’ll discuss a solution to overcoming it. In short: embrace turnover, encourage separation, and don’t even think about saying “careers, not jobs.” Oh yes, it’s Employment 2.0.

Revisiting the Cravath System

Like many 2.0-isms and “innovative” ways of doing business, the “Up or Out” solution to our personnel crisis is not new. Paul D. Cravath first implemented it at the turn of the century. Not this century, of course, but the last one.

Here’s how the “Cravath System” works. Bring lots of new employees in, team them up with mentors, provide real work to do, and give them a choice: either get lots of great experience and get out, or work hard for a higher-up position. Whenever you hear someone aspire to “make partner”, he’s undoubtedly working at a firm that’s adopted this model.

Since its inception in the early 1900’s, the Cravath System has spread to tens of thousands of different companies in different professions, ranging from accounting to urban planning. Robert T. Swaine, in his 1947 book The Cravath Firm And Its Predecessors, describes the result of its use:

Under the “Cravath system” of taking a substantial number of men annually and keeping a current constantly moving up in the office, and its philosophy of tenure, men are constantly leaving… it is often difficult to keep the best men long enough to determine whether they shall be made partners, for Cravath-trained men are always in demand, usually at premium salaries.

Sound familiar? If we “black box” our current process and the Cravath System, they’re practically the same thing: lots of new hires of varying skill come in, and mostly talented workers come out. Yet, somehow, our box gets mucked up with the “residue”, while theirs stays a well-oiled machine. There’s a good reason for this: instead of fighting to retain top talent, we need to make top talent.

A Reality Check

Let’s not ignore the elephant in the room: employees will quit. No matter what you say, no matter what cushiony benefits you give, no matter how hard you try, they will leave you. It’s just a matter of “when”.

In almost every job I’ve had, giving my two-week notice was like an awkward, uncomfortable break-up. “Really,” I’d say time and time again, “it’s not you, it’s me.” It seemed no one understood that it was “just that time”. Worse still, they’d often decline my offer of thoroughly training a replacement and would sometimes even terminate my employment on the spot. This was truly their loss: when I’d leave, I’d take all intuitional knowledge they paid me to learn on my own, and not distill it for my successor.

The reason that I (and many of you) have had these similar quitting experiences is because many employers – despite having been employees themselves – don’t want to accept the fact that employees quit. Some even desperately try to change the fact. I can’t count the times I’ve heard “we offer careers, not just jobs” and “we’re more like a family than a company.” Interestingly enough, those companies tend to have the most mature dead-sea cycles.

Employees – especially the most talented ones – are not “dating around” and moving from place to place in search of the Perfect Company at which they can grow old and retire at. They’ve already aced the first four rungs of Maslow’s hierarchy and are in search of self-actualization: the instinctual need of humans to make the most of their abilities and to strive to be the best they can.

This point bears repeating. Indefinite retention is impossible; employees always quit. The key part is understanding why, and how to leverage this inevitability towards everyone’s advantage.

Why the Skilled Quit First

Bruce did an excellent job of explaining why the unskilled don’t quit:

They tend to be grateful they have a job and make fewer demands on management; even if they find the workplace unpleasant, they are the least likely to be able to find a job elsewhere. They tend to entrench themselves, becoming maintenance experts on critical systems, assuming responsibilities that no one else wants so that the organization can’t afford to let them go.

The reason that skilled employees quit, however, is a bit more complicated. In virtually every job, there is a peak in the overall value (the ratio of productivity to cost) that an employee brings to his company. I call this the Value Apex.

On the first minute of the first day, an employee’s value is effectively zero. As that employee becomes acquainted with his new environment and begins to apply his skills and past experiences, his value quickly grows. This growth continues exponentially while the employee masters the business domain and shares his ideas with coworkers and management.

However, once an employee shares all of his external knowledge, learns all that there is to know about the business, and applies all of his past experiences, the growth stops. That employee, in that particular job, has become all that he can be. He has reached the value apex.

If that employee continues to work in the same job, his value will start to decline. What was once “fresh new ideas that we can’t implement today” become “the same old boring suggestions that we’re never going to do”. Prior solutions to similar problems are greeted with “yeah, we worked on that project, too” or simply dismissed as “that was five years ago, and we’ve all heard the story.” This leads towards a loss of self actualization which ends up chipping away at motivation.

Skilled developers understand this. Crossing the value apex often triggers an innate “probably time for me to move on” feeling and, after a while, leads towards inevitable resentment and an overall dislike of the job. Nothing – not even a team of on-site masseuses – can assuage this loss.

On the other hand, the unskilled tend to have a slightly different curve: Value Convergence. They eventually settle into a position of mediocrity and stay there indefinitely. The only reason their value does not decrease is because the vast amount of institutional knowledge they hoard and create.

Shaping the Value Apex

There’s an entire mini-industry out there that helps companies stretch the value apex. Just googling “employee retention” brings back myriad results and ads, ranging from books to seminars to consultants. The value proposition of these various products is simple: spend some money now to retain employees longer, thereby saving more money later in turnover costs.

However, the value apex can only be stretched so far. At some point, the cost of retaining – be it through salary increases, motivational programs, or creating a Neverland with free food, free toys, and exuberant goof-off time – exceeds the cost of turnover. Regardless of how much a company spends on this – too little, too much, or just enough – it does not change the fact that the value apex exists.

After stretching, there’s only two ways to further optimize the value apex: by accelerating the value-growth curve and terminating it as close to the as the apex as possible. Both of these are accomplished through the Cravath System.

A Culture of Quitting

We’ve all experienced how managers and higher-ups dance around the fact that we’ll quit someday. The justification given for why a process should be documented is almost always “because you might be hit by a bus tomorrow” (or the less macabre “win the lottery”). Since neither is within the realm of reasonable probability, this transitional documentation is often half-assed with the understandable “you’ll have more things to worry about if I get hit by a bus” attitude. But imagine if the justification for documentation was different:

I need you to document this process in detail so that any yahoo can understand it a year from now after you’ve left.

I’ve never had a manager or higher-up ever put it that way. In fact, many people feel that’s an even more stolid justification than “hit by a bus”. But it isn’t; it’s just reality. Why not accept it?

Of course, that justification would never even need to be given if a company embraced a culture of quitting. If they were upfront with their employees and said something to the effect of, “we know that you’re not going to retire here; in fact, after two to three years, we know you’ll be ready to move on to a different job. But before that happens, we want to make sure that you feel that you’ve done an excellent job here and are leaving with some solid experience under your belt. Of course, there are a handful of architect and management positions available, but you’ll really need to demonstrate commitment before even being considered for those. Obviously, that path isn’t for everyone.”

Imagine how much different things would be if you were told that on your first day. Just about every task you do would be in consideration of your successor. Not only would you take pride in solving problems – and, of course, getting strong ROR (Return on Resume) for those solutions– but you’d also take pride in knowing that the guy who comes after you will have an easy time picking up your work. Just as your predecessor did for you.

The benefits don’t stop there. A company with a culture of quitting does not have ex-employees; they have alumni. This is far more than a semantic distinction. An alumni relationship is positive; something that people can take pride in; and one that keeps the door open for further opportunities on both ends. Let’s face it; we’re already curious about our former workplaces and try to keep up through former coworkers. It’d be that much easier if the company facilitated this in some manner.

The alumni relationship also helps with the flow of new personnel. While ex-employees are be hesitant to recommend the company they “broke up” with, alumni will champion it to colleagues in need of similar experience. Furthermore, there’s no sense of defeat when an alumni returns – armed with experiences from other organizations – for another tenure.

For consulting companies or services firms, maintaining a solid relationship with alumni is an excellent avenue to find new business. Who better to recommend as a vendor than a company that one had first-hand experience working at?

But perhaps the most important benefit to a culture of quitting is that it effectively flushes out the residue of unskilled employees. When someone hasn’t moved up or out after a few cycles, it becomes painfully evident who the weakest link is. Everyone – even that certain someone – knows that they’ve long outstayed their welcome. If the sheer awkwardness of being “that guy” doesn’t cause him to leave on his own, and he still doesn’t get it after being asked to resign, then certainly no one will miss him when he’s inevitably let go.

Bringing Home Change

Obviously, this article has painted some incredibly broad strokes, the largest being the stark dichotomy between skilled and unskilled developers, and the lack of distinction between organizations. While this doesn’t change the fact that a value apex exists, it does change its shape. Generally speaking:

The higher-up the position, the longer the curve. Changes tend to occur much more slowly at the top. For example, a basic “refactoring” of a department’s teams could take well over a year to implement.
The greater the skill, the shorter the curve. Ambition and skill go hand-in-hand, and ambitious individuals tend to want swift changes, and quickly lose motivation when these don’t happen.
The larger the company, the shorter the curve. Large teams are generally not receptive to ideas from the new guy, leaving a large part of contribution (i.e. past experience) wasted. Furthermore, promotions are often based on tenure, not skill.
The smaller the company, the longer the curve. Smaller companies, on the other hand, are more receptive to change, allowing one to contribute past experiences for a long while.
The less skill-demanding the company, the significantly longer the curve. Not all companies need top talent. For example, the company who needs only maintainers of an ancient COBOL application might be best fit with curves that are closer to the value convergence.

One important point to keep in mind, too, is that skill is not measure of overall worth. At some point in our lives, many of us no longer look towards our career for self actualization. For example, many feel that having a family provides much more self actualization than a career, and choose not to work those sixty hour weeks to meet those tight deadlines. And there’s nothing wrong with that.

That said, we still need to bring these changes to our industry. Obviously, we can’t all implement the Cravath System overnight. For many companies – especially those who really don’t need skilled developers –a full-fledged Cravath system will never be a good fit.

But there is one thing that we all can do. In fact, let’s all do it together, right now, right this moment. Employees, go ahead and say to yourself:

I know that I will quit my job, and there’s nothing wrong with that.

Now it’s your turn, employers/managers:

I know that my employees will quit, and there’s nothing wrong with that.

Once we’ve all accepted this, things will start to work better. Eventually, we’ll join the legal industry, the accounting industry, and so many others, and we too will have our well-oiled machine. But first things first: we need to embrace quitting, not fear it.

Brought to you by the Non-WTF Job Board: