DevDisasters

Out To Lunch

Why user requests shouldn't always be granted.

• By Mark Bowytz
• 02/19/2014

Tom had made a regular habit of taking a post-lunch-hour coffee break in the office break room for the past couple of days. All week, the IT muckety-mucks were in all-day meetings to discuss the work related to the new acquisition of Qwerty Logistics Corp. Of course, in the interest of keeping the flow of productivity going, lunches were catered.

On Monday, the food was fantastic: There were aluminum trays still filled with chicken, green beans and red potatoes. Tuesday wasn't nearly as fancy -- just a few trays of sandwiches -- but they were from that expensive sandwich place nearby and were simply delicious. Wednesday was tacos, burritos and nachos with all the fixings. Today, however, was a bit of a mystery -- Tom swore he saw a Mac's Pizza truck get buzzed through the security gate around 11:30, but he wasn't entirely sure. In any case, with 1:00 p.m. looming, the leftover wagon would be arriving soon and Tom was positioned to have first dibs on food that would surely be better than the Smart Cuisine he had stowed in the office fridge earlier in the week.

As the door to the conference room started to open, Tom's stomach started to rumble in anticipation, but instead of holding a stack of pizza pies, it was his director motioning for Tom to come over. Tom acknowledged and made his way to the conference room.

Tom hoped that this was the "Come here and help me with all this food!" wave, but his gut told him that a reheated frozen meal was in his future.

Wrong Place at the Wrong Time
Tom scanned the room looking for familiar faces, but there weren't any besides his director and his director's boss. The bold, red T's on the others' badges made clear they weren't from around here -- they were from the to-be-merged company … and none of them looked entirely pleased.

"Hey, Tom, sorry to pull you in like this, but we've been seeing a lot of errors come up during our test runs of Qwerty Logistics apps on our boxes -- none of which are very helpful -- and it's getting to be so much of a problem that we can't get anything done ... here, see what I mean."

Tom's director pointed to a remote desktop session being shared to all in the room via the conference room's big screen. It appeared to be an ordinary data entry form with several carefully aligned, ordinary-looking fields ... except for a tiny pop-up window with a Yellow exclamation icon with the following:

Cannot save date value or date invalid format. (Err: 0x000074478A75)
Field entry 'SC' cannot be null. (Err: 0x00002F1D454B)
Data entry audit failed. Did not update record. (Err: 0x00006CC882F6)

The director took off his glasses and rubbed his forehead.

"We're pretty much dead in the water until we can get through these errors, and my boss is asking for a time line on something I don't know. We can't afford to let these problems linger. We need a developer's set of eyes on this problem ASAP ... we need for this to be your top priority."

Tom wasn't sure just what to think -- this was some serious stuff, with big-name players all staring at him for some direction. Despite his nerves, Tom somehow managed a reply: "Yes. I'll see what I can do."

Tom noticed the visitors' faces seemed to relax a little at the announcement that someone was on the case. Sadly, he didn't share their optimism.

Poking Around By the time Tom made it back to his cube, with heat-`n-eat frozen meal in hand, an e-mail had landed in his inbox with the address and credentials to the sandbox environment the Qwerty Logistics app was running on temporarily, and a screen capture of the data entry form and its error messages.

Once he remoted into the sandbox server and got himself acclimated, Tom did find one ray of hope: a folder named "SourceCode" off the root of C: Drive. It didn't give any insight into how these errors happened, but it was at the very least something to go on. Inside the folder was a Visual Studio project file. Not wanting to upset the balance of the universe, Tom copied the source folder locally and opened the project from his own machine.

Once Visual Studio had its act together, after uplifting the project from Visual Studio 2005 with minimal warnings (thank goodness), Tom searched the source files in the solution for the code behind the screen.

It took a little while, but Tom deduced that each of the cryptic error messages really boiled down to one thing: "Configuration file not found."

In the haste to set up a sandbox environment, someone had simply skipped the step of including a file named CONFIG.XML. This resulted in date-format errors since the default format mask wasn't known, the internal field containing the Site Code was now null, and the app couldn't save the record because the database connection was missing.

Tom navigated to the install directory for the application, renamed Config.XML to CONFIG.XML and miraculously, everything worked. But one detail remained: What was going on with those weird error codes that looked like memory addresses?

As it turns out, that was the funny part of the whole ordeal.

Pick an Error, Any Error! Tom sent a simple "It works now" IM to his supervisor who in return requested Tom's immediate presence in the conference room.

Upon arrival, Tom informed the room as to the nature of his (ridiculously) simple "fix" with an accompanying quick demonstration and then proceeded to open a Word document with the following code:

private String ErrCode()
{
  // Make errors more random
  System.Threading.Thread.Sleep(20);
  Random rnd = new Random();
  int errCode = rnd.Next(12000, 34000);		
  return "0x0000" + errCode.ToString("X") + (errCode+5678).ToString("X");
}

(You can see a live demo of the code running here: dotnetfiddle.net/JAoPjy.)

Tom explained that while he didn't expect anybody in the room to be a developer, it was important to point out the proof that the "error codes" were merely random numbers converted to hexadecimal values with a "0x0000" added to it.

"So, while the error messages are real," he said, "The codes are completely meaningless."

"Oh, we know about that," dismissed one of the Qwerty Logistics managers.

"One of the original user complaints was that text error messages didn't look enough like real errors," added another manager. "Many users know that errors with hexadecimal addresses appear in bad things like blue screens, so the decision was made to add them to the error messages."

Tom was visibly shocked. How did they support anything? Why would anybody fulfill such a pointless user request? Tom would have probably stood there for the rest of the afternoon asking numerous questions had his director not placed a hand on his shoulder.

"Great work there, Tom! Hey, why don't you grab an extra boxed lunch over there before it makes it out to the break room?"

Tom perused the stack of extra boxes, picked a good one, and quietly left the conference room -- all the while hoping that Qwerty Logistics developers were being acquired as part of the merger.