Side Channel

At the university where Diogo worked, the Computer Science program outgrew its status as an unloved child of the Mathematics department. It was to become its own department, and that meant it finally deserved its own building. Since the university in question had a very strong architecture program, the university searched for the biggest names to design the building.

Enter Laurent. He flew in to consult and prepare designs for the building; he was fresh off a project in Dubai and his next port-of-call was Tokyo. He was a name that could name names. The exterior renders he provided were stunning, full of glass and sweeping lines. The designs leapt up on a desk, stomped their feet and screamed, "I AM MODERN AND TECHNOLOGICLYISH!" To the casual spectator, they were fantastic. As Diogo discovered, when you actually had to live in the building, things got much worse.

"I assume," Diogo said during one conference with Laurent, "there will be some sort of freight elevator? The server room we're moving in involves a great deal of heavy equipment, after all."

"No, no!" Laurent smiled like he was revealing a fabulous Christmas gift. "There is no need. You see, there is an access door on the south wall, with a ramp into the basement. Your computers can go in through there."

"Well, yes," Diogo agreed, "but how are we going to move them up to the server room?"

"Up? There is no up! The server room is in the basement. Nothing heavy need go upstairs; we have no need for a freight elevator."

"I'm not sure that's a good idea," Diogo said. He explained the unique geography of the region.

Laurent extolled the virtures of his choice. It would be easy to move equipment in and out of. The naturally cooler basement would be cheaper to keep cool, reducing the costs of running a large server farm. The lack of a freight elevator would reduce the initial construction costs. Diogo continued his protests, carrying his case before the dean and eventually the university president, but their response was simple: "Laurent is a world class architect. He knows what he's doing. What buildings have you designed?"

Laurent came with a stack of designs and left with a gigantic check for his efforts. The CS department moved into their new building while the president gave his ribbon cutting speech. For most of the summer session, things were sunny and bright, and the new building worked out spectacularly. Shortly before the fall semester kicked into full swing, it rained. It kept raining for a full week, at rates ranging from a drizzle to a torrent. By the third day, Diogo was looking into renting a gondola for his commute. By the fourth, the water table rose and filled basements across the entire county.

Diogo's home was well prepared for this sort of flooding, common to the region. The basement was unfinished, the furnace was on blocks, and an emergency drain shunted the flood waters into the storm sewers. The new CS building wasn't so fortunate. As Diogo waded through the waist deep muck and murk in the basement, Jacques Cousteau swam between his legs, searching for the mysterious creatures of the deep ocean. Anything in the server room that had been below shoulder height had at least some water damage; anything below waist height was a complete loss. In the darkened room, Diogo feared that at any moment an upsurge of water would dash him against the ceiling and drown his unconsious body.

"…which is exactly what I warned you about," Diogo told the dean. It was impolitic, but honest.

The flood dampened the president's enthusiasm for the new building. Diogo and the other stakeholders sat down to plan a solution that would minimize downtime and get servers running for the CS labs before the fall semester started. Diogo proposed moving the surviving equipment back into its old room in the Mathematics building, but the dean vetoed that. "We are, after all, an engineering school. We should be able to do better than that."

The next day, workers swarmed the CS building, armed with large diamond-tipped saws and laser measures. On the top floor, they cut a hole on the roof of the building and installed large double doors. Of course, they opened to a four story drop that ended in a sloped ledge on the third floor of the building. A few days later, a large crane trampled the delicate landscaping and hoisted the rack equipment and surviving servers through the doors. Workers moved it from the ledge into the new server room a few feet away. "There," the dean said, "that should solve your little flooding problem." His tone implied that the whole thing had been Diogo's fault for having servers in the first place.

Through most of the fall semester, things went swimmingly- or not, as the case may be. The basement flooded several more times, but the server room was safe on a higher floor, potected by altitude and fire doors on all the stairwells. Rumors spread about the door to nowhere, and the fact that it had no lock, which earned it the nickname "the Suicide Door".

In early April, Diogo walked up the stairs towards the server room and opened the fire door, only to get doused with six inches of water that had pooled around the door. He waded to the server room, only to find that the puddle extended to the UPSes and destroyed several thousand dollars worth of equipment.

The winter had left a full pack of snow and ice on the roof of the building. When the weather finally warmed, it melted, and attempted to run off the roof. Unfortunately, the easiest route downwards was through the hastily installed and poorly sealed "Suicide Door", and was trapped on the upper floor by the tightly sealed fire doors.

North Korea is a strange place. From what I've read, it's as close Hell on Earth as any other place, and their sole economic output appears to be YouTube videos featuring their Mass Games. Oh, and don't even get me started on that whole Dear Leader thing.

But no matter, North Korea is pretty full of itself and, as Rick O'Shay noticed, their website coding is no different: it's really, really strong. See for yourself on the Official webpage of the Democratic People's Republic of Korea (yes, it's a .com):

Though, in fairness, who are we to question such STRONG web design? Dear Leader is, after all, an internet expert.

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

The first sign that this installation would be different was Mike's numerous contacts with the Tim, the client's project manager and IT administrator. A simple request for a list of the twenty-odd users of the software was like a conversation with an eight-year old.

"What format do you want the list in?" Tim asked, "I could send it in Excel, Word, Access, or CSV."

"Any of them is fine," Mike replied, "all I need is a list of names, emails, and departments."

"Are you sure don't have a preference?"

"No, it's only a couple dozen users," Mike re-explained, "we're just going to type them in by hand."

"I'll do Excel then," Tim said, "this way, you can import it. What other fields? I can give you their hire date, birth date, etc."

"Excel will do..." Mike paused, "but all I need are names, emails, and departments; our software doesn't store any other fields."

"I'll put in dates. Do you prefer text, numeric, or date-time formats?"

The dialog dragged on and on, as Tim continued to ask questions about what fields to sort on, how he planned to import the data, whether boolean values should be numbers or letters, and so on. Mike just gave up, and decided to wait until he'd arrive on location to input the data. Sure, he would have less time for Freecell this trip, but typing in a few dozen records wasn't very time consuming.

Surprise Visit

When Mike and his colleague arrived at the site, they learned that Tim hadn't bothered to tell anyone that highly-paid consultants were coming to install software and train the team. Presumably, he was too busy sorting and re-sorting Excel spreadsheets.

But not to worry, Tim could fix it. Without even asking Mike, he pulled together everyone in the office for an "emergency training" meeting. That's when Mike explained that it was standard procedure to install the software before training people on how to use it.

There was also one other small problem: Tim neglected to complete any of the prerequisite steps for installing their software. Well, it was small in comparison to the other problem: Tim didn't have the key to the server room or even administrative access to the server. While Tim worked to track down the network administrator (who happened to be on vacation), Mike's colleague did what little training he could, allowing Mike to get in a few good hours of Freecell.

Anything you can do, Tim can do better

Later that day, Mike was able to work with the fairly disgruntled network admin to configure the server and get their software up and running. This meant that they could resume training first thing in the morning. At least, that's what they thought.

Instead of letting Mike and his colleague run the training session, Tim had some other priorities. He explained at length that he already knew how to use the software because, after all, he knew .NET. Of course, even if the software were written in .NET (it was Java-based), the knowledge was as relevant as metallurgy is to driving a racing car.

Tim then grilled Mike as to whether or not the software would work as a "thin client." It was a web-based application, so the answer was clearly yes, but the point of confusion was apparently the definition of "thin client." What Tim actually meant was some computer he had with small chassis.

Then Tim demanded to know if the software would work with terminal services, since he didn't like coming into the office. He even wasted everyone's training time by explaining how he would convert the GUI text into Spanish. Finally, when he saw a PGP file, he commended Mike's team for using "Plain-Good Privacy" security methods.

Solving the Tim problem

This process continued through the first half of the day, and Tim's constant questioning did nothing more than confuse the users in the room. Mike realized that supporting a poorly trained staff would be a nightmare once they got back home, so he came up with an idea.

"We've got an emergency we need your help," Mike told Tim after lunch, "we need a list of people who are participating in the training. It's a high priority, so could you work on that while we continue training?"

"Sure, sounds easy enough. I'll have it for you right away", Tim replied.

Mike handed Tim a flash drive and smiled, knowing that he had taken the bait. A little later, Tim returned with the drive and Mike popped it in his system. Before Tim had an opportunity to interrupt the training session with another question, Mike pre-empted it with a request. "That's great Tim, but can you also add the phone number and office extension?".

"No problem Mike, I'll get right on it!"

An hour later, Tim returned again with the drive. "Wow, that's even better," Mike responded, "but could you sort by employee last name and shorten the job title field to 30 characters max? It needs to be just right."

The process continued for a few more iterations, and Tim seemed genuinely happy that his meticulous expertise was being utilized. More importantly, without Tim in the training session, they were able to finish up and even cover some of the advanced features. As Mike was packing up to hurry off and catch a plane, Tim handed him the final result of all of his "coding".

"Here's the data you requested. I put it together just the way you wanted!"

"Thanks Tim, I'll take a look at it on the plane."

After his second expense-accounted drink of the flight, Mike plugged Tim's USB stick into his computer and promptly selected the Format Disk option. Content in the knowledge he had resolved the "Tim" problem, Mike decided to take a nap for the rest of his flight home.

Kevin S. works on websites for a living.

Well, actually, "work" might not be an adequate description considering that part of Kevin's job requires that he is half clarvoyant and half mountain sherpa when it comes to digging through the several huge codebases globbed together abominations of open source, third-party components that he is expected to support.

Case in point - Kevin was tasked with fixing a bug on a site that, on the surface, seems to work alright, but under the hood it's an organizational nightmare.

The actual website exists in a /site/ subdirectory of the main www folder on the customer's server, which is duplicated two more times under a /site2/ and /site3/ folder, each of which have their own installation of Joomla combined with a mix of randomly installed components and cgi scripts, which may or may not relate to the site's content.

But the best and most WTF inducing discovery is this function he found in a file named "learn.php"...and "learn2.php", and "learn3.php", and "learn.old", and "learn.orig.php"...

<? //convert month number to month name function monther($inter){ $months = array("Apples", "Jan.", "Feb.", "Mar.", "Apr.", "May.", "Jun.", "Jul.", "Aug.", "Sept.", "Oct.", "Nov.", "Dec."); if($inter == 1){ echo $months[1]; } else if($inter == 2){ echo $months[2]; } else if($inter == 3){ echo $months[3]; } else if($inter == 4){ echo $months[4]; } else if($inter == 5){ echo $months[5]; } else if($inter == 6){ echo $months[6]; } else if($inter == 7){ echo $months[7]; } else if($inter == 8){ echo $months[8]; } else if($inter == 9){ echo $months[9]; } else if($inter == 10){ echo $months[10]; } else if($inter == 11){ echo $months[11]; } else if($inter == 12){ echo $months[12]; } } // end converting month ?>

"Considering what happened," wrote Ben, "I felt this error message to be quite self explanatory."

 

"All I wanted to do was to find a replacement remote to a Yamaha receiver," writes John C., "Instead, I found myself spending the rest of the day typing!"

 

"It's great to see CSS and HTML in the news," Paul Compton writes, "but personally, I'm hoping to see some JavaScript to keep the coverage balanced."

 

 

"After seeing the rather unusual validation rule below while trying to book a holiday recently." writes Ruth,"I decided to take the old-fashioned route and simply booked my reservation over the phone."

 

"Unfortunately, I was absent that day in back in 3rd grade when they covered the |ECL000|SI multiplication tables." Yahel writes.

 

Daniel F. wrote, "Apparently, my screen resolution goes all the way up to '11'."

 

"I noticed the below when registering on a seemingly legit secret shopper site," wrote Wolf, "I guess they're using some kind of new 'metric inches'?"

 

 

The Command Center Administrator (from Joshua Knarr)
A job listing email for a "Command Center Administrator" recently found its way to my inbox. The message was from ACME COMMERCE, which was apparently an UP AND COMING company that would be HUGE AND SUCCESSFUL if they could keep their INTERNET STORE FRONT FOR SPORTING GOODS going. The position was offered to me in fits of caps lock, and it was tough to understand if they were merely excited, or if someone was playing Mad Libs with Job Listing Generator 3.0. I decided they were simply excited to be expanding, so I dutifully sent along my résumé and asked if they had a job description for the Command Center Administrator position.

Moments later, my phone rang. It was Krishna from ACME COMMERCE. "Very nice résumé," she said, "we would like to interview you! What time can we set this up?"

"Thanks Krishna," I responded, "what is the Command Center Administrator position all about?"

"Oh it's a very good position," she replied, "I can tell from your résumé you would be a good fit!"

"Okay... but what does a Command Center Administrator do?"

"Well, you can ask all the questions you want at the interview we shall set up! What time are you free?"

We set up a phone interview for later that day and, when the time came, my phone rang. It was Krishna again. Apparently she was the one conducting the phone interview.

She started by asking, "what's your expected compensation?"

"Well," I paused, not wanting to start the conversation with salary, "what are some things a Command Center Administrator does?"

"You know standard functions," she said confidently, "it is a very standard position."

"OK..." I stumbled, "so... like a Systems Administrator?"

"Well it is a Command Center Administrator. What compensation would you be asking for this position?"

It seemed like Krishna was either being dishonest or simply had no idea what the position was about. Either way, I figured it wouldn't hurt to give a number.

"Oh very good," she responded to my salary requirement, "this is right in our range! This concludes the phone interview and I will be sure to send your résumé along to the hiring manager. You can expect a call back from us shortly!"

An hour turned into a day, a day turned into a week, and soon enough, I had mostly forgotten about ACME COMMERCE, their SPORTING GOODS INTERNET STORE FRONT, and the COMMAND CENTER ADMINISTRATOR. And then my phone rang. It was Krishna checking to see if I'd be available for an interview the following week.

I was available and, if nothing else, was dying to know what a Command Center Administrator was.

When I arrived, Krishna wasn't in the office and the receptionist didn't know who else to contact. After I suggested a few key-words like "IT" and "command center", she decided to try the network operations manager. He, in turn, said to call the development manager, who, in turn, hastily picked one of his developers and sent him down to meet with me.

As the developer led me towards the conference room, we walked past a room with glass walls that housed a rather impressive set-up: several employees intently staring at a few large plasma screens that displayed all sorts of graphs, charts, spinning things, and blinking lights. The developer tapped on the glass, and commented how fun it was that they had their own "fishbowl". I chuckled, figuring that it was some kind of inside joke.

We arrived in the conference room and he opened up with, "mind if I spend a minute reading your résumé?"

I handed him a copy and sat there in awkward silence. Shortly thereafter, he complimented the formatting and asked me what the last non-technical book was that I read.

"Uhm," I tried to remember,"This Old House's 1001 Woodworking Projects, I think."

"Oh, very nice," he nodded, "well, to be honest, I don't really have any questions."

"Okay," I said as he stood up, "seriously though, what is the command center administrator?"

"Oh, that position?" he shrugged, "I don't know. I think it's one of those guys in the fishbowl."

I never heard from ACME COMMERCE again... which is too bad, because I still have no idea what a Command Center Administrator does.

 

Tier-3 Supporting (from Catherine Dunham)
Last year, my company opened up another Tier-3 Applications Support Analyst position for our team. Although it may sound like an inflated title, it's a pretty intense position: it requires 10-years experience designing, building, and supporting multiple large-scale applications. Our clients are not retail customers who need help with a mouse, but more Fortune 500 Companies who need help optimizing their terabyte-sized datasets with our software.

I mention this because we state all of this on our job listings and make it clear that candidates need to have a history of being able to support large-scale systems. So, it was rather surprising to see Human Resources forward a résumé to my team. Under technical skills were listed:

• Tier-3 supporting facebook
• Tier-3 supporting google
• Tier-3 supporting internets explorer

And the list went on. Not only that, there was a five year gap in the applicant's work history which was explained with simply "stay at home mother." Of course, that in and of itself is not a problem if the technical skills are kept up to date, but it became increasingly obvious that this applicant had no technical skills to start with and her "Tier-3 support" referred to running said websites and applications on her home computer.

We thanked Human Resources for the résumé and told them that we would not be inviting the candidate in for an interview. A little while later, the Director of Human Resources told us that yes, in fact, we would be interviewing the candidate and gave us a few dates that the candidate would be available. Not wanting to start any fights with Human Resources, we brought her in for interview.

"Disaster" doesn't begin to cover what the interview was like.

Firstly, the candidate showed up in stained tracksuit bottoms and a t-shirt that looked like it had been used to clean sump pumps in the local sewage works. After about five minutes in the conference room, it became apparent that her shirt smelt like it too. Willing to give her the benefit of the doubt (maybe she'd driven into a sewage pipe on the way in?), we ploughed on.

When we got to the technical portion of the interview — that is, the simple stuff like "describe the steps of restoring a SQL database from backup" — she flipped on us. Extending her index finger as to scold us, she advised us quite proudly that she'd "never have to do that kinda shit" and that she would expect us to "fix those kinda things."

My manager asked her just what it is she expected this job to be about. Her reply has been forever burned into my memory.

"I get paid. If you expect me to deal with all that computer shit, I'll go off on stress leave and sue you."

Not only did she not get the job, but we had a very stern word with Human Resources that, in future, we won't interview anyone we deem unsuitable.

 

The Best Job I Didn't Get (from Phil M)
It was a small company with a big title — Software Architect — and I figured it'd be worth check out. My interview was with the president of the company, and his leading technical question was something like, "so let's say I wanted a site with a menu on it, but I wanted to be able to define that menu any way I wanted to, redefine it on the fly, with as many sub-menu headers that I want —"

Having heard the type of question a hundred times, I nodded and cut him off. "You want a recursive algorithm that reads from a table in a database? Or, do you want to drive it from XML?"

"Oh I see," he smiled, "you know about that."

"It's a pretty common problem," I responded, "there's also plenty of third-party libraries, depending on whether you're talking web, Windows, or whatever."

"Great great," he said, "definitely web. So, can you go design that for me and make it work?"

Programming practicals are always fun in an interview, so I asked a few technical questions. Turns out he wanted a demonstration in ASP.NET using SQL Server, which I told him would take me about thirty minutes to complete.

The president pointed me to the PC next to the receptionist's desk and told me to go to town. After about thirty seconds, I told him that there was no database server to be found. They had installed Visual Studio and SQL Server's management tools, but there was no indication as to where a SQL Server database was located.

"So what do you need?" he asked me.

"A database server," I said, "more specifically, just a connection string so I can create a database for this exercise. Or, if SQL Server isn't available, I'll need something else like Access or MySQL. Alternatively, I can develop this using XML or something."

The president was adamant that the exercise be database-driven. And two hours later, I was still waiting for a database. Apparently, their network guy had better things to do and wasn't too keen on having me install anything on the computer. I explained teh scenario to the president, and told him that I had to get going.

"So," he said to me, "you don't know how to do this?"

"I can do it fine," I responded, "it's just you don't have a setup that allows it. Do you want me to use XML instead? Or I could just make you a project from home and email it to you?"

"No, that will be fine." he scoffed, "I expected it to be completed here, and you were unable to do it. I've got your résumé on file."

I was a bit bummed at first, but have come to realize it's probably the best job I've never had.

As we learned in Unit Tested, when you require that developers — especially those "certain" developers — write more unit tests, you'll get exactly what you ask for: more unit tests.

Johnny Biggg, whose company recently mandated this, knows this all too well. Although the ratio of testing-to-functional code went up, the quality (or lack thereof) remained about the same. Well, that is, unless you consider how often arrays can fail in JavaScript.

function doTest() { var oTest = new Object() var oTest2 = new Object() var oFn1 = function(b){alert("fn1: " + b)} var oFn2 = function(c){alert("fn2: " + c)} var oFn3 = function(d){alert("fn3: " + d)} var a = new Array() a.push("hello") a.push("goodbye") a.push(1) a.push(2) a.push(true) a.push(oTest) a.push(oTest2) a.push(oFn1) a.push(oFn2) if (!(a.contains("hello") && a.contains("goodbye"))) { alert("failed test: string not found, but should be") return false } if (a.contains("byebye")) { alert("failed test: string found, but should not be") return false } if (!(a.contains(1) && a.contains(2))) { alert("failed test: number not found, but should be") return false } if (a.contains(3)) { alert("failed test: number found, but should not be") return false } if (!(a.contains(true))) { alert("failed test: boolean not found, but should be") return false } if (a.contains(false)) { alert("failed test: boolean found, but should not be") return false } if (!(a.contains(oTest) && a.contains(oTest2))) { alert("failed test: object not found, but should be") return false } if (a.contains(new Object())) { alert("failed test: object found, but should not be") return false } if (!(a.contains(oFn1) && a.contains(oFn2))) { alert("failed test: function not found, but should be") return false } if (a.contains(oFn3)) { alert("failed test: function found, but should not be") return false } if (a.indexOf("hello")!=0) { alert("failed test: index not correct for string") return false } if (a.indexOf(1)!=2) { alert("failed test: index not correct for number") return false } if (a.indexOf(true)!=4) { alert("failed test: index not correct for boolean") return false } if (a.indexOf(oTest)!=5) { alert("failed test: index not correct for object") return false } if (a.indexOf(oFn1)!=7) { alert("failed test: index not correct for function") return false } alert("passed all tests") }

When you work in IT, your family turns to you as the ultimate computer expert. Since Reggie worked in IT for the direct mail industry, not only did he get carpet bombed with the usual computer questions, but also with questions about the piles of junkmail his family received. "Why do they send so many? How do they afford that?" "Is the furniture store really going out of business?" "I got the same thing twice. Do you think I can double up the coupons?"

Reggie could never quite make them understand that there were many companies in the direct mail industry, and that his company only provided address lists. He knew less about the actual mail his family recieved than they did. No explanation helped; his association with the industry made him an expert on all things postal. blockquote { border-bottom: 1px black dashed; border-top: 1px black dashed; padding: 10pt; }

Reggie's company assembled a new release of their web application for generating address lists. The previous release had allowed customers to retrieve names and addresses, but many customers had lobbied for a cheaper (for them) alternative. They wanted just the addresses and a "slug", like "To our neighbor at", "To the petlover at", or "Resident", and they wanted to be billed accordingly.

It had been a simple enough change, although it was bundled in with a lot of other minor improvements. Coordinating the release and making sure clients knew what to expect was a significant undertaking. On the last day before the official go-live, Reggie pulled up the requirements document to review it while writing up the release notes. 14.3 On the field selection screen(Fields.jsp), a checkbox will be added and labeled 'Use slug'. If it is checked, 'THE SLUG' will be used. (see screenshot)
The requirement seemed straightforward enough, but as Reggie reviewed the document, something seemed… absent. He read through the whole thing a few times, checked the attached screenshots, and then fired up the new version of the application to confirm.

At no point did the requirements specify an input field to define what the slug should be. Since it wasn't in the requirements, it wasn't in the application. Since it wasn't in the requirements, no one tested for it. In fact, QA had signed off that the requirement was complete and that, when checked, the application generated data using "THE SLUG".

Reggie generated the same data set twice, once using names, the other using the slug. The first try worked as expected: John Adams, 111 Street St, Townton, NY 11111-1111
Thomas Jefferson, 111 Road Rd, Townton, NY 11111-1111
Burt Reynolds, 111 Lane Ln, Townton, NY 11111-1111 But the second attempt confirmed what he feared: To THE SLUG at, 111 Street St, Townton, NY 11111-1111
To THE SLUG at, 111 Road Rd, Townton, NY 11111-1111
To THE SLUG at, 111 Lane Ln., Townton, NY 11111-1111

This was bad news, but it wasn't the end of the world- at least they caught it before the official go-live. Reggie hurried down to his boss's office. "We need to postpone the go-live. I know this is short notice, but a delay is better than putting it out into production…" Reggie stopped when he saw the look on his boss's face. "… it's already in production, isn't it."

"One of our major clients paid extra to get pre-release access. They've been using it for two weeks." Reggie's boss sighed and said, "I'll take it from here. Who knows? Maybe they haven't been using that feature."

That faint hope was dashed when Reggie's mother called a few hours later. "Can you believe the nerve? They called me a slug! A SLUG! Are they trying to make a joke? Because it's not very funny!"

On a recent airplane flight, I happened to catch the movie Groundhog Day. Again.

If you aren't familiar with this classic film, the premise is simple: Bill Murray, somehow, gets stuck reliving the same day over and over.

It's been at least 5 years since I've seen Groundhog Day. I don't know if it's my advanced age, or what, but it really struck me on this particular viewing: this is no comedy. There's a veneer of broad comedy, yes, but lurking just under that veneer is a deep, dark existential conundrum.

It might be amusing to relive the same day a few times, maybe even a few dozen times. But an entire year of the same day -- an entire decade of the same day -- everything happening in precisely, exactly the same way? My back of the envelope calculation easily ran to a decade. But I was wrong. The director, Harold Ramis thinks it was actually 30 or 40 years.

I think the 10-year estimate is too short. It takes at least 10 years to get good at anything, and alloting for the down time and misguided years [Phil] spent, it had to be more like 30 or 40 years [spent reliving the same day].

We only see bits and pieces of the full experience in the movie, but this time my mind began filling in the gaps. Repeating the same day for decades plays to our secret collective fear that our lives are irrelevant and ultimately pointless. None of our actions -- even suicide, in endless grisly permutations -- ever change anything. What's the point? Why bother? How many of us are trapped in here, and how can we escape?

This is some dark, scary stuff when you really think about it.

You want a prediction about the weather, you're asking the wrong Phil.

I'll give you a winter prediction.
It's gonna be cold,
it's gonna be gray,
and it's gonna last you for the rest of your life.

Comedy, my ass. I wanted to cry.

But there is a way out: redemption through repetition. If you have to watch Groundhog Day a few times to appreciate it, you're not alone. Indeed, that seems to be the whole point. Just ask Roger Ebert:

"Groundhog Day" is a film that finds its note and purpose so precisely that its genius may not be immediately noticeable. It unfolds so inevitably, is so entertaining, so apparently effortless, that you have to stand back and slap yourself before you see how good it really is.

Certainly I underrated it in my original review; I enjoyed it so easily that I was seduced into cheerful moderation. But there are a few films, and this is one of them, that burrow into our memories and become reference points. When you find yourself needing the phrase This is like "Groundhog Day" to explain how you feel, a movie has accomplished something.

There's something delightfully Ouroboros about the epiphanies and layered revelations in repeated viewings of a movie that is itself about (nearly) endless repetition.

Which, naturally, brings me to A/B testing. That's what Phil spends most of those thirty years doing. He spends it pursuing a woman, technically, but it's how he does it that is interesting:

Rita: This whole day has just been one long setup.

Phil: It hasn't.

Rita: And I hate fudge!

Phil: [making a mental list] No white chocolate. No fudge.

Rita: What are you doing? Are you making some kind of list? Did you call my friends and ask what I like and what I don't like? Is this what love is for you?

Phil: This is real. This is love.

Rita: Stop saying that! You must be crazy.

Phil doesn't just go on one date with Rita, he goes on thousands of dates. During each date, he makes note of what she likes and responds to, and drops everything she doesn't. At the end he arrives at -- quite literally -- the perfect date. Everything that happens is the most ideal, most desirable version of all possible outcomes on that date on that particular day. Such are the luxuries afforded to a man repeating the same day forever.

This is the purest form of A/B testing imaginable. Given two choices, pick the one that "wins", and keep repeating this ad infinitum until you arrive at the ultimate, most scientifically desirable choice. Your marketing weasels would probably collapse in an ecstatic, religious fervor if they could achieve anything even remotely close to the level of perfect A/B testing depicted in Groundhog Day.

But at the end of this perfect date, something impossible happens: Rita rejects Phil.

Phil wasn't making these choices because he honestly believed in them. He was making these choices because he wanted a specific outcome -- winning over Rita -- and the experimental data told him which path he should take. Although the date was technically perfect, it didn't ring true to Rita, and that made all the difference.

That's the problem with A/B testing. It's empty. It has no feeling, no empathy, and at worst, it's dishonest. As my friend Nathan Bowers said:

A/B testing is like sandpaper. You can use it to smooth out details, but you can't actually create anything with it.

The next time you reach for A/B testing tools, remember what happened to Phil. You can achieve a shallow local maximum with A/B testing -- but you'll never win hearts and minds. If you, or anyone on your team, is still having trouble figuring that out, well, the solution is simple.

Just watch Groundhog Day again.

[advertisement] JIRA Studio - Hosted software development suite. Build better software. Faster. Free trial »

Tom G. recently joined a team that maintained a fairly large Java client/server application. His first task was fairly simple: prepare for a switch to a different server farm by going through the code to make sure it was portable and wouldn't be affected by a new server, IP address, and so on.

After a few days of browsing through line-after-line of tedious code, Tom found a pretty unique "helper" class: Compare.java. In addition to swathes of unnecessary comparison code, there was equalsAllowNull. Enough was enough, so Tom got up, walked over to his colleague who worked on another project all together, and vented about ridiculousness of Compare.java, and the rest of the code.

//this method will allow me to compare strings and Integers, will be //used in all the equals methods in all report components for which //i write test cases works like a regular equalsIgnoreCase except: // - passing 2 nulls returns true, // - passing 1 null 1 non-null string returns false, // - passing 2 strings falls back on equalsIgnoreCase() public static boolean equalsAllowNull(String s1, String s2){ return equalsAllowNull((Object)s1, (Object)s2); } public static boolean equalsAllowNull(Object s1, Object s2){ if((s1 instanceof String) && (s2 instanceof String)) { return (s1 != null) ?((s2 != null) ?(((String)s1).equalsIgnoreCase(((String)s2))) :false) :true; } else if ((s1 instanceof Integer) && (s2 instanceof Integer)) { return (s1 != null) ?((s2 != null) ?(((Integer)s1).equals(((Integer)s1))) :false) :true; } else { System.err.println( "this is an error from equalsAllowNull() method only " + "accepts String or Integer, what the hell did you do?! "); return false; } }

The developer behind Compare.java must have heard Tom’s rant, as later that day, he sent a message to the team that the code in Compare.java was “tweaked” to be more efficient.

//this method will allow me to compare strings and Integers, will be //used in all the equals methods in all report components for which // i write test cases works like a regular equalsIgnoreCase except: // - passing 2 nulls returns true, // - passing 1 null 1 non-null string returns false, // - passing 2 strings falls back on equalsIgnoreCase() public static boolean equalsAllowNull(Integer s1, Integer s2){ return (s1 != null) ?((s2 != null) ?(((Integer)s1).equals(((Integer)s1))) :false) :true; } public static boolean equalsAllowNull(String s1, String s2){ System.out.println("strcmp 1:"+s1+" 2:"+s2); return (s1 != null) ?((s2 != null) ?(((String)s1).equalsIgnoreCase(((String)s2))) :false) :true; }

Unfortunately, he didn’t hear Tom loud enough.

"I was a bit surprised to see a debit for my phone bill for $40.01 instead of the normal $40.00," writes Ben Hitchcock, "looking at the actual statement cleared things up."

 

Erich writes, "Word wrap? Word wrap!? We don't need no steenking word wrap!"

 

"Apparently, Chrome is unsupported at NBC.com," writes Danny, "hmm... let's see, maybe I should try using Chrome instead?"

 

Alex notes, "the interesting thing is that it managed to change my password even though it gave me that error."

 

"I thought I'd try my hand at some mobile development," wrote Paul V, "does anyone know where I can buy some more XPVCOM?

 

"I saw this error message at a Singapore Mass Rapid Transit station," writes Cyril Boh, "it did not actually count down from 3 and the text did not change in the twenty minutes I was there. I can't help but wonder what device was actually under the threat of being rebooted."

 

"I was trying to print a jpeg image when i got this error," J W noted, "it seems pretty clear what the problem is."

 

"A user at my company was entering a new customer in our (third-party) logistics software and made a frightening discovery," writes Bob De Mars, "we can no longer have customers with the letter 'h' in the name!"

 

Prisoner of Process was originally published in Alex's DevDisasters column in the August 01, 2007 issue of Redmond Developer News

When Eric C. arrived at his new job, it was with a huge sense of relief. His old workplace had been a haven for cowboy coders and anarchic hackers, where the only semblance of consistency was in everyone's preference to modify code directly in production.

"Finally," Eric thought as he flipped through the Developer's Handbook. "Real processes!"

It's not as if Eric was a paper-pushing Process Nazi. He was just happy to see a bit of structure. But as he delved deeper into the handbook Eric grew worried. The processes seemed designed for a behemoth organization that had user advocates working with defect analysts to assess and manage issues in their software. But this company was a small financial services firm with no more than 30 employees. Eric paused, reassuring himself. "They can't be using this! It's probably just some old manual from the boss's previous job." He tossed the binder on his shelf and fired up Visual Studio.

The next few days went surprisingly well. Eric's coworker printed out a stack of issues for him to work on, and, one by one, Eric made his way through CAPP (the firm's core, in-house application) and resolved them. It was a great learning experience: He got to know the business, he figured out CAPP and he gained a strong understanding of its design. In less than a week, he was a bona fide CAPP expert.

Then Eric overheard one of the data processors chatting with Eric's manager. "But then, when I click here," Eric heard, "CAPP sets the asset value as blank!" Eric was used to overhearing the data processors' conversations. They all worked in a small room and sat no more than six feet from each other.

Eric had worked on the affected code, and began to chime in to the conversation when his boss interrupted.

"I'm sorry," Eric's boss said, "I know you're new here, but we all really need to follow procedure. Did you get a copy of the Developer's Handbook?"

Eric stuttered, trying to figure out his faux pas. "I, um, yes." Then it hit him. He recalled the specific rule he had violated.

It was in the Defect Pre-Assessment Stage: "To ensure developers aren't bogged down with unneeded defect assessment, only user advocates shall communicate with end users in this stage."

By the Book

Having skimmed the Developer's Guide, Eric had another look. The Defect Resolution process read as follows:

1. Upon encountering a potential program defect, the user shall immediately cease performing any further actions in the application and shall e-mail his or her user advocate (i.e. Eric's boss).
2. The user advocate shall immediately go to the user's workstation (which always required him to pass by Eric's) and then meet with the user (which always happened within arms-reach of Eric).
3. After discussing the potential defect, the user advocate shall send an e-mail to a defect analyst describing the potential defect and requesting that an issue be created.
4. The defect analyst shall then create an issue in the defect database (an Excel spreadsheet), assign a defect number (best guess at creating a unique, 12-digit random number) and fill out a defect report (a Word document on a network share).
5. During their weekly defect-prioritization meeting, the development manager (also Eric's boss) and the defect analyst (the only two attendees) shall meet and assign defects to one of the three programmers.
6. The defect analyst shall then update the defect database (both the spreadsheet and the document) with the assigned programmer and e-mail the programmer a copy of the issue report.
7. After the programmer notifies the defect analyst of the resolution, the defect analyst shall notify the QA manager (also Eric's boss) during their weekly proposed-defect-resolution meeting (again, with only two attendees).
8. If the resolution has any problems, the QA manager shall notify the development manager (perhaps in a meeting with himself?), who shall notify the defect analyst in the weekly defect-prioritization meeting, who shall then notify the original programmer, who shall then repeat the previous step.
9. Once the resolution is deployed, the QA manager shall request that the defect analyst close the issue at the next weekly defect-prioritization meeting.

Over the ensuing months, Eric couldn't resolve a single defect. With an average feedback cycle of two weeks and all "outside protocol" communications forbidden, even the simplest change took months to resolve.

However, on Eric's last day at the firm, rumor had it that the QA manager was "seriously considering" notifying the closing of Issue #182749384701 -- the one Eric had been given four months earlier on his first day on the job.

"Some time ago I was checking the business logic that a friend had done for a system." writes Brian, "While I was debugging, I found this awesome piece of code. I understand that application logic should be bulletproofed to handle any kind of data condition passed to it, nulls, double and single quotes, etc., but I felt this to be an example of over-engineering a solution."

public boolean isBooleanFalse(boolean value) { boolean response = false; if (value == true) { response = false; } else { response = true; } return response; }

"However, at least I now know that, if passed, FILENOTFOUND will resolve to true."

We're still on Summer Break here at The Daily WTF, which means it's time to bring back another classic. But in the mean time, please send in your stories so we'll have plenty to work with when we return next week.

Now what's particularly fun about Banking So Advanced is that it was originally published back on October 17, 2007... and is still relevant today. The article links have not changed and the "unique" code remains the same. Consider what that means in Internet Time: back then, Twitter was little more than a silly idea that most everyone found ridiculous. Okay, so clearly, not that much has changed in the past few years, but I should note that this online banking site is still optimized for "Netscape Navigator 4.75 or higher; Internet Explorer 5.0 or 6.0; and AOL 6, 7, or 8."

A while back, I wrote about US financial institutions, their failure to implement two-factor authentication, and the absurdity that has become Wish-It-Was Two Factor authentication. I thought that'd be the last I'd write about the topic, but when Steven King pointed me towards his bank, Synergy One. I couldn't resist a follow-up.

First and foremost, Synergy One seems to be a great, local institution. They invest in their community. They offer college scholarships. Heck, they even have student-run branches to encourage saving money while in high school. And this is exactly why it's such a shame that they've fallen prey to the Wish-It-Was Two-Factor placebo.

Being such a small institution, Synergy One does not develop their own banking software. They rely on Harland Financial Solutions, who provides "strength and industry leadership within each product" and boasts "over 7,000 clients" to make them "the number one choice for many financial institutions." With a reputation like that, it's no wonder so many banks look to Harland for their technology solutions.

Unfortunately, Harland's online banking product - Cavion® Internet Banking - is woefully inadequate. It does, however, sport several impressive-looking "multi-factor" authentication and security methods.

The first of these - that Synergy One and other unfortunate Harland end-users face - is the almighty CAPTCHA. A technology barely able to curb comment spam on blogs, Cavion® utilizes CAPTCHA as a "Security Code," claiming that it's an "extra security measure used to eliminate fraudsters from randomly selecting account numbers".

I suppose that makes sense. Surely, any fraudster bent on electronic bank fraud would be thwarted by a barely scrambled image that required off-the-shelf optical character recognition software to decode. On the bright side, the system did provide an audio CAPTCHA for accessibility. Granted, the text-to-speech engine sounds like it came from the early-90's, but hey, it's a start!

On the off chance someone might defeat that first bastion of security, Cavion® employs another fool-proof barrier: JavaScript. For those of you who missed their Code SOD today, following is the code that is used to fend off a SQL Injection (as seen on the Enrollment Page):

function isValidValue(stg,name) { var error=""; var rtn=""; stg = stg.toUpperCase(); if (stg.indexOf("DROP")>-1 || stg.indexOf("..")>-1 || stg.indexOf("NULL")>-1 || stg.indexOf("--")>-1) { error = true; } if (stg.indexOf("SELECT")>-1 || stg.indexOf("DELETE")>-1) { if (stg.indexOf("FROM")>-1) { error = true; } } if (stg.indexOf("UPDATE")>-1) { if (stg.indexOf("SET")>-1) { error = true; } } if (stg.indexOf("INSERT")>-1) { if (stg.indexOf("INTO")>-1) { error = true; } } if (error == true) { rtn="You have entered invalid data in your "+name+" \n Please do not use any of the following characters or words: 'SELECT FROM' 'DELETE FROM' 'UPDATE SET' 'INSERT INTO' DROP NULL .. -- \n "; } return rtn; }

If those two security "factors" weren't enough, Cavion® even mandates that you use an onscreen keyboard to type in certain fields:

That's right! You fraudsters have no chance of getting in-- Oh, wait...

... gee, I can't imagine how any would find that difficult to use!

Unfortunately, things go a bit downhill from there.

When you sign up as a customer and enroll in their online banking (something which I think I'll have to pass on), you're required to select and answer a few of those ridiculous "security" questions. Curiously, one of the questions had a rather odd disclaimer:

Steven, who shared these screenshots with me, thought nothing of it. Green was more to his taste, anyway. But when it came time to selecting another question, it became pretty clear why RED was not a valid option.

I guess you're just out of luck if you grew up on 9th, love pie, and just can't get enough CSI (or, god forbid, ER). Your money will be so secure that you won't even be able to figure out what answers you need to type in to access it.

Sadly, Synergy One is one of many that subscribed to this preposterous online banking system. Several others -- San Antonio City Employees FCU, Hudson Valley FCU, Missoula FCU, SRP FCU, and so many more -- have been suckered into Cavion® and its related products. And it just keeps spreading.

So what can we, as security conscious IT professionals, do about this growing Wish-It-Was-Two-Factor Authentication dilemma? Complain. Loudly. A sincere letter sent to a bank Vice President that uses Harland’s - or any other embarrassingly deficient banking software - will certainly plant the seeds of doubt that their system isn't as advanced as they were told. And maybe, just maybe, it will make them wonder, how exactly is preventing "RED" more secure?!

Working as a DBA in academia, Paul received a notice that a certain newly migrated user schema, specifically the one used by the enrollment tracking system, had swelled to 281 tables and was growing. This had struck Paul as being very strange since the tracking system wasn't all that complicated.

When a student is registering for a class, and want to know if there's room left, they need two pieces of information - the Course ID and the Semester Number.

Course IDs are found by simply looking up the course in the Course Catalog. However, the semesters (or terms), denoted by a 4-digit number, can be a little tricky for new students. The first digit denotes the century (2 for the 21st century), the second and third digits are the specific year (08 for 2008, 09 for 2009, and so on) and the last digit denotes the month the term begins (1 for spring term, 6 for the summer term, and 9 for the fall term). Therefore, if you are looking for classes for the Spring 2009 Term use 2091 or if you are looking for Summer 08 classes use 2086, and for Fall 2010 use 2109.

The student enters the Course and Semester code and they get back a count of spaces left in the class.

Thinking that the system should really be, tops, five tables in all, Paul couldn't figure where all the tables were coming from, that is until he checked the layout and found a very creative way of storing data in a database.

Each table was in the format ██_Enroll_hours_<term>_<week> each for enrollment going back in history several years.

Karsten wrote, "seeing the whole undergound train shut down and reboot during the ride was a bit scary."

 

"I just bashed a few keys at random when doing a Google search to check my connectivity," writes Ben, "it looks like the Dartington College of Arts (a real school, I should note!) is really making the most of their Google sponsorship and selling themselves well."

 

"I guess it did certainly take 'a while' for the scan to run," J. Pablo Fernández wrote, "but I'm surprised it advises me to immediately scan again."

 

"This came up at the local A&P grocery store," Chris R notes, "I'm sure glad I'm a Bonus Club member!"

 

"Hopefully I am able to make it to a Best Buy store before 123," wrote Cav, "I don't want my coupons to expire! Although, to their credit, they have known about this since 1."

 

"Check out our great free books," Ben Horton writes, "there only $4.47 each!"

 

[Someone.Frgt.To.Fill.Ths.In] (from Paul Schnei)

 

It's the summer break for The Daily WTF! Please send in your own stories so we'll have some fun ones to share when we return. In the mean time, here’s a fun classic. "The Pie T Department" was originally published on August 8, 2007.

Many years ago, Dan B. worked at a large accounting firm that had several small, satellite offices spread throughout the world. The offices shared data -- mostly email -- via a dial-up based file synch operation that would run several times throughout the day. Since these offices were so small, they didn't need IT support on staff; instead, they'd rely on the IT staff at the central office for help.

The file synching had been going well for months, but the process began failing when attempting to synch with one of the Australian offices. Dan tried to diagnose the problem on his end, but determined that it had to be a problem with the remote server in Australia. It was going completely offline every few days and had to be manually restarted. Unable to convince his boss that a trip to the outback was needed, he had no choice but to work with the office's secretary, Sydney, to fix the problem.

For a few weeks, on and off, Dan walked Sydney through all of the common diagnostic steps. Having all but ruled out software issues, Dan started thinking that the problem could be with the server overheating.

Dan: Is there an air conditioner running in the server room?
Sydney: Yes. Well, I mean, not in the cupboard, but there's air conditioning in the room.
Dan: "The cupboard?"
Sydney: Yeah, the cupboard in the kitchenette.
Dan: Oh. That could be an issue... are there any vents or fans on the cupboard?
Sydney: Well, no. But Boyd usually leaves the cupboard doors open.
Dan: Hmm... it could still get hot in there...
Sydney: It doesn't get too hot, though, it works perfect for the pies.
Dan: "The pies?"
Sydney: Yeah, the monitor gets pretty hot, so Boyd and some of the other folks use it to warm up their meat pies in the morning.
Dan: ...
Sydney: I'm sorry... are you... crying?

As it turned out, warming up lunch on the server was part of the problem. The other problem was the type of lunch: while scones and bagels were perfectly safe, the meat pies ended up tripping fat down the back of the server into the PSU, tripping it off until it was restarted manually.

Fortunately, Dan was able to offered simple solution: use the microwave instead.

Varg's colleague had an awfully difficult problem challenge to solve: remove the language parameter ("lang") from a query string.

Well, difficult for Varg's colleague. Though most of us would apply some substring finesse, this particular developer hammered away with a brute force approach.

Dim MyPage As String = Request.Url.ToString MyPage = Replace(MyPage, "&lang=en", "") MyPage = Replace(MyPage, "&lang=gr", "") MyPage = Replace(MyPage, "&lang=EN", "") MyPage = Replace(MyPage, "&lang=GR", "") MyPage = Replace(MyPage, "&lang=En", "") MyPage = Replace(MyPage, "&lang=Gr", "") MyPage = Replace(MyPage, "&lang=eN", "") MyPage = Replace(MyPage, "&lang=gR", "") MyPage = Replace(MyPage, "&LANG=EN", "") MyPage = Replace(MyPage, "&LANG=GR", "") MyPage = Replace(MyPage, "?lang=en", "") MyPage = Replace(MyPage, "?lang=gr", "") MyPage = Replace(MyPage, "?lang=EN", "") MyPage = Replace(MyPage, "?lang=GR", "") MyPage = Replace(MyPage, "?lang=En", "") MyPage = Replace(MyPage, "?lang=Gr", "") MyPage = Replace(MyPage, "?lang=eN", "") MyPage = Replace(MyPage, "?lang=gR", "") MyPage = Replace(MyPage, "?LANG=EN", "") MyPage = Replace(MyPage, "?LANG=GR", "")

Upon seeing this solution, Varg replied to his coworker, "this doesn't seem to cover the '?LaNg=en' and '&lANg=gr' scenarios." I'll let you guess how the code was updated to include those.

It's the summer break for The Daily WTF! We're working on some fun new stories now, but in the mean time, here’s a fun classic. "Anything You Can Do Lyle Can Do Better" was originally published on May 21, 2008.

If Lyle could be summed up in one word, it'd be "competitive." If he could be summed up in three words, it'd be "ultra-competitive jackass." If you had $21.00 on you, Lyle would make it a point to have $21.50. If you estimated that a task would take you twelve hours, it'd take Lyle eleven hours and 45 minutes. If a distant relative died, somehow two of Lyle's distant relatives died. He was the kind of guy that would play basketball against a nine year old to win, then he'd make fun of the kid for losing, then he'd make fun of the kid for crying. If a stranger asked Lyle what time it was, he treated it as a challenge.

Lyle was two levels above James W. in the company hierarchy (or, as Lyle would probably call it, "winning"). James reported to Rob, who reported to Lyle. Another team of the same size reported to Lyle as well. James and one of his colleagues knew about Lyle's obsession with winning and exploited it at every opportunity, usually teasing him to the point that he'd leave them alone. As is the case with most bullies being called out on their bullpucky, Lyle got defensive and eventually stopped visiting James during the day.

Clearly, there were problems with the team (and not with Lyle), so he had to take action. I'm better at team building than anyone else, Lyle reasoned. Time for a team-building exercise!

And he knew just the place, too: Lazer Zone X-Treme 2000!! It was the ideal environment for IT office team building — screaming children, sticky arcade cabinets, blaring nu-metal — paradise within just a few miles of the office. He sent emails to his two teams inviting them to play laser tag.

Everyone carpooled to LZXT2K (Lyle got there first), and stood in line waiting to sign in (Lyle signed in first). The teams in the laser tag game were the same as the teams in the office, with Lyle joining the team opposite James. They entered their names, put on their vests, and began the first of two games.

While James was skeptical of laser tag for team building, he had to admit that it was a good time and that everyone enjoyed the friendly competition. Everyone except Lyle, that is. Whenever he was hit, he'd throw up his arms and complain that he shot first and his gun wasn't working. Whenever he landed a hit, he'd laugh and praise himself loudly in third person. "How are you so awesome, Lyle? I don't know, Lyle, I just can't help it!"

The first match was neck-and-neck throughout, until James's team barely pulled ahead at the end. While everyone else was laughing and comparing score sheets after the game, Lyle sat in the corner scowling at his sheet.

"OK, tough guys," Lyle said, rising from his seat and crushing his score sheet in a clenched fist, "how about for the next game the losing team has to sing the 'I'm a Little Teapot' song here in the lobby!"

James rolled his eyes, realizing that it must've taken Lyle tremendous strength of will to not be howling profanities at his team. Everyone agreed to the wager before the second game began.

Five minutes into the game, James was getting the sense that something was amiss. Lyle's team had more than three times the score of James's team, and James could hardly land a shot on anyone! At one point, James had snuck up behind someone on the opposite team, and from three feet away couldn't get their vest to register a shot.

It was a laser tag massacre — James's team had lost by over 1,000 points by the end. And Lyle couldn't have been happier. "OK, let's hear it," he insisted with a toothy smile.

"Just one second," James said loudly enough for all to hear. He went over to the kid running the system to do some detective work.

"So... 'Skippy,'" James began, reading the kid's nametag. "I'm curious — is there a way to turn off all the vests on one team?"

Skippy immediately broke eye contact, looking down at his desk. After a pause, he sheepishly replied "yeah..."

"And did that guy over there ask you to turn off the vests for his team?"

"Y... yeah... He asked me to turn all of them off except one."

"Thanks." James excused himself and returned to the group.

Lyle still had a huge smile on his face. "Ah, so the losers came back! Have you got something you'd like to say, or perhaps, sing for us?"

James shot a disgusted look at Lyle, and after a brief, awkward silence, the teams returned to their cars. Lyle got back to the office first.

A few days later, Lyle sat James down to take him to task for figuring out his subterfuge. James was surprised that he was the one being admonished. "It's just that I didn't want my team feeling bad about losing twice," Lyle explained.

"No one would have felt bad," James explained. "Everyone was having a good time! Nobody was talking trash or trying to make one team feel bad." Well, except you, James thought.

Hopefully the next team-building exercise, a small company picnic, won't be sabotaged by Lyle.

"This one had me so confused it made me ponder my existence," writes Jack M.,"and I remain subscribed to the list."

 

"If their ad is any indication of how I should be writing web code," wrote Kevin, "then I don't wanna be right!"

 

"So where exactly is the FIFA World Cup being held this year?" Michael Wood writes, "South Afmerica??"

 

 

The below, submitted anonymously, is either meant to give the viewer an impression of Hertz's worldwide presence or the web developer haphazardly chose a list of "countries".

 

"I was reinstalling the HTC sync application on my computer," wrote Jeff, "but apparently it has been using, or is being used...or something. I think."

 

"Found this in my local Morrisons," Gareth writes, "where it seems they pass the negative savings onto the customer."

 

"I've always known that Flash is bloated and stinks," wrote Chas., "now I know why."