Bert Glanstron, Greg thought to himself, why does that name sound so familiar? Bert… Glanstron… did I work with him? Did he go to my high school?

Saying the name a few more times didn’t help jog Greg’s memory, so he shrugged his shoulders and double-clicked on the résumé. It was the eleventh in a row he had reviewed for a programmer analyst position, and it somehow was even less impressive than the previous.

“DOS? ZMODEM? WWIV!?” Greg exclaimed, drawing a quizzical look from a fellow subway passenger. Ten years ago, Bert Glanstron’s listed skills were considered to be long outdated. Today, they’d be about as relevant as a telegraph apparatus repairman. As Greg went to hit the delete key, his peripheral caught one more outdated keyword: FIDONet.

Normally, FIDONet wouldn’t have even given him pause, but seeing that word on the résumé of one Bert Glanstron did a whole lot more. It brought back a long-lost memory of computer days past. More specifically, the memory of one Bert Glanstron.

FIDONet Flashback

It was July of 1988 and Greg had a bit of a lawn problem. No matter how much he watered or fertilized, he couldn’t get rid of a dead spot on his grass. Being the computer-savvy guy that he was, he fired up Telix, dialed into his local BBS, and posted a message to a FIDONet lawn care feed.

Among other things, FIDONet served as a dial-up based, distributed message board and was a precursor to internet forums. Users would dial-in to their local BBS’s and, a few times a day, the BBS would dial out and synch messages with FIDONet nodes. Like today, maintaining civil and productive discussions was a challenge, and as a result, many FIDONet feed moderators required that subscribers to their feed use real names instead of handles.

The day following his lawn care question, Greg logged back into FidoNET to see if anyone replied. Instead of advice, he found a mouthful from the lawn care feed’s moderator, one Bert Glanstron. It read something like this.

Dear SARUMANATEE, In case you can’t tell, this is a grown-up place. The fact that you insist on using your ridiculous handle clearly shows that you’re too young and too stupid to be using FIDONet. Go away and grow up. Sincerely, Bert Glanstron

Shocked, Greg apologized and explained that he had no idea why his handle was showing up in the messages. The feed clearly indicated that no handles were allowed, and Greg didn’t have a choice as to what name was displayed on the posted messages.

Apparently dissatisfied, Bert responded with “you are an idiot and should be banned from your mommy and daddy’s modem.” He then sent a note to the sysop of Greg’s BBS expecting that SARUMANATEE be banned for committing such a grave offense. Of course, seeing that it’s the sysop’s responsibility for ensuring the appropriate name is sent to FIDONet, the sysop apologized to Bert and said it was his fault for not synching properly, and advised that it wouldn’t happen again.

Still dissatisfied, Bert went on a tirade and posted a campaign of messages that demanded justice. “This BBS is exactly what’s wrong with FIDONet,” he’d rant, “they are dragging down the whole system with their idiocy! I insist that they are cut from FIDONet completely!”

Greg didn’t care enough about his lawn problem to battle it out, so he simply unsubscribed from the lawn care feed and left it at that. The local nursery helped him fix his grass, and both FIDONet and Bert Glanstron faded into unremarkable memories.

Bringing Him on In

“Oh. My. God.” Greg unintentionally muttered aloud, drawing another look from a commuter. Terrible résumé notwithstanding, he absolutely had to meet Bert Glanstron. The following day, he asked HR to bring the candidate in for an interview. He wasn’t sure what he’d say, but there was just something... well, just about him being in a position to interview Bert.

When the day finally came, one of Greg’s colleagues – a manager of another development group – had the pleasure of interviewing him first. “I know you selected this guy,” he told Greg, “but he’s definitely not worth your time. Trust me. Want me to boot him out?”

There was no way that Greg would miss the opportunity to meet the man himself, so he politely declined the offer and inquired as to why it was a bad interview.

“So you know how I get my boys donuts for the Monday meetings?” the manger rhetorically asked, “I had the box of donuts on my desk for later, and as I was going through his résumé, he popped the tape seal and helped himself to a donut. I mean, there was a whole stack of papers on the box of donuts, and he moved them to the side.”

Greg’s eyes lit up. Bert Glanstron was already turning out to be more than he could have ever imagined. As the development manager told the story, Greg pictured exactly what Bert must look like: a short Al Pacino wearing a tracksuit and a couple large gold chains.

“And this was all without even asking! I told him, ‘um... those are for a meeting… later’, so he put the donut back in the box. After taking a huge bite out of it. Really! Now who does that? I mean… what do you even say after that!?”

Greg was stunned. He absolutely, positively had to meet Bert Glanstron. He wasn’t sure what was going to come out of it, but he knew it’d be exciting.

The Interview

When Bert Glanstron was finally brought to Greg’s office, he was a bit taken back by his appearance. Bert wasn’t anything like the New Jersey stereotype he had pictured.

Bert Glanstron was an older fellow, possibly in his late 50’s. He wore brown shoes, white socks, and brown polyester slacks that were a good three-inches too short. His button-down, short sleeve shirt was ledger yellow with thin blue, lines in a graph paper pattern and opal buttons trimmed in silver. As for the blazer, it was tweed and sported elbow patches. And it too was about three sizes too small for his portly belly. He also had a long, wispy beard, a bald head, and wore black, horn-rimmed glasses. All told, he was straight out of a 1962 yearbook photo of a math professor… with a little powdered sugar from the last interview in his beard.

The interview started with a standard course of questions, and Bert’s answers were as expected. He didn’t know a lot about modern technology, whether it was TCP/IP, port assignments, or even HTML.

Greg’s mind turned towards the sinister and, as if he were toying with his prey, Greg asked about his experience on FIDONet. And boy-oh-boy, Bert lit up like no one had ever asked him that question.

For twenty straight minutes, Bert babbled on and on about WWIV, the glory of the BBS days, and how the World Wide Web was a ruination of all that was good and text based. He knew ANSI codes, VT100 escape codes, and all manner of telnet MUDs and such. Bert was the guy and was proud of all of his sweeping – and probably exaggerated – accomplishments in the FIDONet and PODnet realms.

Of course, Greg didn’t need a single one of those skills. But that didn’t stop him from prodding.

“Very interesting,” he wryly smiled, “changing subjects here… did you ever have a conflict with someone that turned ugly? And how did you resolve it?”

Without even a hint of sarcasm, Greg said ever-so-sweetly, “actually, I don’t think I’ve ever had a conflict with anyone.”

An Ugly Conflict

Shocked and insulted by Bert Glanstron’s blatant disregard for his past offenses, Greg hastily stood up, knocking his chair back. He diabolically snarled, “what’s wrong Bert Glanstron, don’t you remember me?”

Greg depressed a button he had built just for that occasion, causing the lights in his office to dim and the dark and dangerous sweeping crescendo of a Danny Elfman soundtrack to start playing. He continued on his rant and tirade.

“It’s me, SARUMANATEE from the FIDONet of yore! My ire will cast dispersion on you and your puny, buster brown loafers. Now it is I who shall ban you. Mwa ha ha ha ha! Where’s your FIDONet kingdom now, Bert Glanstron? ”

Actually…

At least, that was one response that Greg considered. Instead, he amicably said “well, you do seem like an easy-going guy,” and ended the interview shortly thereafter.

Unsurprisingly, the interview was a waste of time for all parties involved. Yet, Greg was still vastly satisfied in a guilty sort of way: he finally got to meet Bert Glanstron.

James sent in today's snippet with virtually no introduction; just six, measly words: "the grass is definitely not greener." Normally, that'd be a bit frustrating, since it's always nice to know a little history or background about the code. But like those six word stories, James told the classic tale of the young and burgeoning software developer who’s always looking to expand his professional purview by seeking out new opportunities to learn and sharpen his skills, only to find his efforts frustrated by a “seemed good on paper” job that leads to nowhere – or worse – towards destitute and despair.

Well, either that, or this code really speaks for itself. Maybe it's the generic Util class which acts as a dump for random methods. Perhaps it's the alphabet array with an extra Z. Or it could be that method for turning letters into numbers.

/** * The utilize methods. */ public final class Util { /** * The ARRALPHALET chars . */ private static final String[] ARRALPHALET = new String[] { "Z", "A", "B", "C", "D", "E", "F", "G", "H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T", "U", "V", "W", "X", "Y", "Z" }; /** * the count ARRALPHALET chars. */ private static final int VALUE = 26; ...snip... /** * @param decimal * @return */ public static String dec2Alpha(final int decimal) { final ArrayList<String> arrResult = new ArrayList<String>(); int a = decimal; int b = decimal; do { b = a / VALUE; final int c = a % VALUE; if (c == 0 && b == 0) { arrResult.add(0, "0"); } else if (c == 0 && b != 0) { b = b - 1; arrResult.add(0, ARRALPHALET[c]); } else { arrResult.add(0, ARRALPHALET[c]); } a = b; } while (a > VALUE); if (a != 0) { arrResult.add(0, ARRALPHALET[a]); } return StringUtils.join(arrResult.toArray()); } }

Alex G. writes, "This is what my GPS had to say when I was trying to find a lookout in Cabris in the South of France."

 

"You'd think machines were invented to uncomplainingly perform repetitive tasks. Nobody realizes that they could - like humans - hate their ungrateful low-paying jobs." writes Giannis.

 

"It was taking forever to update my ESXi server, so I decided to force a reboot and I received the following error," Erik wrote, "However, I'm not sure that I agree..."

 

"I love my phone. I has tons of features, received a lot of positive good reviews and I was able to get a great deal after a rebate," wrote Ben,"I just wish it had a bit longer battery life."

"I forgot my password and tried to reset it," writes Brian M., "but in order to do so, I had to answer perhaps the most secure security questions I'd ever seen."

"On first glance some would say calculation mistake," writes Faruk,"but I call it a very productive two hours."

 

"I was having some trouble with removing the Microsoft Office 2010 Beta and installing the RTM when I saw this error message," writes Rob, "I had to just give up. If Microsoft Word can't start Microsoft Word what hope do I have?"

 

It's baaaaaack...yep it's THAT time again.  It's Share Your Bizarre Email day!

"This one by far is the greatest email I have ever received," wrote Kelly, "Apparently, corporate IT support is the great know it all!"

Sent: Thursday, February 01, 2010 2:03 PM To: Info Tech Subject: Aloe Vera whole leaf.. Hi, I have just purchased a whole leaf Aloe Vera. Someone told me to grind the whole leaf with a grinder and add a little water. Please, can someone tell me if it is safe to drink the solution this way or is there other method of processing it? Thanks! Joan

 

"Being a computer science major, I'm used to being asked idiotic tech questions," Kyle writes, "but this one stood out."

 

"Our SVN server has been flaky today, going down and coming back up without warning, and generally disrupting engineering," writes an Anonymous submitter, "I just received the following email:"

 

To: Engineering CC: Ops Subject: SVN Back up (once again) For those interested, we figured out what it is. Apparently the power cable to queen (the machine running SVN) was loose. And whenever the server room was opened, the machine would reboot. And the reboot did not start the Heartbeat service within SVN. So Ops is shoring up the power cable, and we should be good to go.

 

"As it turned out, every time Ops would go into the closet to see what's wrong with the SVN server, it would go down again...and again. I do not dare to think of what our colo must look like."

 

"At my work, it's all fun and games until someone disobeys the company's email policy," wrote Ian.

 

From: Joe Miller Sent: Wednesday, January 21, 2009 9:40 AM To: Bill Smith; All Users Cc: Carrie Jones. Subject: RE: Email communication Oops!!! I forgot to copy Carrie. c.c. Carrie Jones. Joe A. Miller, MBA Sr. Vice President, RANDOM FINANCIAL SERVICES COMPANY Securities offered through Broker/Dealer, (Member ABCD,EFGH) Investment advice offered through RANDOM FINANCIAL SERVICES COMPANY, a registered investment advisor. > ------------------ > > From: Joe Miller > Sent: Wednesday, January 21, 2009 9:39 AM > To: Bill Smith; All Users > Subject: RE: Email communication > > Bill, > > I request that you re-consider your attached request. That arrogant request is not the Bill Smith > that recruited me 9 years ago. You were considerate, polite, and humble. > > Please tell me you didn’t mean it the way it read? > > Think about it, you chastised someone for simply not “replying” to your email a few weeks ago. > Now your saying that you may not even READ yours, much less reply? What happened to our company being “family”? > > Here’s hoping the Bill I know comes back into King Bill’s body. > > Respectfully, > > Joe A. Miller, MBA > Sr. Vice President, RANDOM FINANCIAL SERVICES COMPANY > > Securities offered through Broker/Dealer, (Member ABCD,EFGH) > Investment advice offered through RANDOM FINANCIAL SERVICES COMPANY, a registered investment advisor. > > > > ------------------ > > > > From: Bill Smith > > Sent: Tuesday, January 20, 2009 5:38 PM > > To: All Users > > Subject: Email communication > > > > I have made this request before but it bares repeating since it is still not happening. Carrie Jones > > should at least be copied on all emails to me. In fact, I prefer you send them to her unless they are private. > > She will get them to me. If you send to me without ccing her, it is 50/50 if I see it or not. > > > > Thank You, > > > > Bill W. Smith, President > > Registered Financial Consultant > > Random Financial Services Company > > > > Smith Service Team > > > > Joe xxx 321-456-1724 > > Kelly xxx 321-456-1726 > > Carrie Jones 321-456-4882 > > Brandy xxx 321-456-4884 > > Jill xxx 321-456-4883 > > Steve xxx 321-456-1736 > > > > Securities offered through Broker/Dealer, (Member ABCD, EFGH) > > Investment Advice through RANDOM FINANCIAL SERVICES COMPANY a registered investment advisor.

Got a bizarre email that makes you go "WTF"? Well, then go on and mail it in!  

"Recently, I inherited an ASP.NET web application that hadn't been touched in many a year," wrote Scott Schottler, "I was pleasantly surprised to see that, not only did it successfully convert from a Visual Studio 2003 project, but that it actually built without errors."

"Of course, my excitement soon waned when I looked into the code. Now we've all seen the Try-Catch-Gulp pattern, but this is ridiculous."

Public Function GetDAO(ByVal typeName As String) As Object Try Return Activator.CreateInstance(System.Type.GetType(typeName, True, True)) Catch ex As ArgumentNullException Throw Catch ex As ArgumentException Throw Catch ex As NotSupportedException Throw Catch ex As Reflection.TargetInvocationException Throw Catch ex As MethodAccessException Throw Catch ex As MemberAccessException Throw Catch ex As Runtime.InteropServices.InvalidComObjectException Throw Catch ex As Runtime.InteropServices.COMException Throw Catch ex As TypeLoadException Throw End Try End Function

Christian’s first day at his new job started out just like many others in the professional IT world.

“Welcome aboard!” exclaimed Brian with an outstretched hand, “Great to see you again, c’mon in and we’ll get you all set up.”

Brian took Christian to the security room to get his ID badge and toured him around for a meet and greet with the other departments.

“Communication is key around here,” explained Brian with a sweep of his hand, “We have these half-wall cubicles installed for good reason! The server, infrastructure, and database teams all work closely with each other on a daily basis.”

Pleased that he had chosen a good IT organization to work for, Christian inquired what server platform they ran PHP on.

“Umm…that’s the thing, you won’t be developing in PHP,” explained Christian’s manager, “we use something else.”

“We use BobX.”

It’s Better than PHP!

Swallowing the reactionary urge to blurt out "WTF am I doing here then?”, Christian calmly asked for some explanation, after all, when he interviewed with Brian for a PHP position and all of the technical questions related to hardware demands, logical approaches and pitfalls with regards to developing web applications in…PHP.

“You see, we've had a lot of previous developers just couldn’t keep up with Bob,” Christian's new bossed grinned, “he’s a bit of a recluse, but boy-oh-boy is he sharp. You’ll learn a lot here, and you’re a pretty smart guy, so I’m sure you’ll keep up just fine.”

Brian went on to explain that the IT organization had somewhat shadowy figure in the form of a recluse programmer on its payroll. Brian explained that he had never exactly met Bob, the inventor of BobX, face to face, and in fact nobody in the company had. However, years ago back when the term “Information Superhighway” was all the rage, based on total cost of ownership, BobX was chosen for all web development in the corporation.

“To be frank, I don’t know if Bob lives on a boat, a nuclear bunker, a shack in the woods, or down the road, nor do I care,” explained Brian, “but I do know this – finance has cut him a check every month for the past 10 years and he provides servers, environments and adds features to BobX freeing up the guys here to handle everything else.”

For a second, Christian considered that handing back his badge and walking out, however, after some thought, he decided to take it in stride in a "let's see where this goes" sort of way.

Christian decided to give being a full-time BobX developer a shot.

Might as Well be Brain Fu**ed

Some languages work out really well because they make it easy to work on abstract problems, many are designed to work in enterprise environments, and others have advantages of being really fast. However, Christian came to learn was that BobX was in fact none of these.

In his first "simple" task, Christian needed to change the ordering of a single screen in the company’s in-house developed ERP system. In many languages, this would be a ten minute job, with five being spent searching for the code in source control. But not in BobX.

As Christian came to learn, rather than SQL queries (which were deemed "security risks" in the documentation), BobX relied on things called "assistants". Configured on a screen that makes nuclear reactor control panels look simple, you could create, modify, or delete assistants or join together two or more assistants to create a super-assistant. However, there was one little 'gotcha' - you couldn't concatenate fields "on the fly" when returning results. This limitation resulted in many workaround fields named "CustomerNameFirstnameLastname" and "CustomerInitials" and, of course, gems like "TmpTestingDeleteThis" with comments warning "Do Not Remove or Financials Interface will Break!". Also, as a bonus, no unique identifiers allowed.

"You should consider yourself lucky!" Christian's boss quipped, "We made that interface screen using BobX in house - before, we had to do all that linking by hand!"

When it came time to inspect the "web" source, Christian could tell there was definitely genius at work, but whether or not it was evil, twisted, or evil and twisted, he couldn't tell for sure.

For example, if you need a list, you just say something like this:

<xbobloop statement="AssistantName" > <xbobprint> .. write table content here .. <xbobprint> <xbobendloop>

If parameters need to be initialized, they can be done like this:

<xbobdefine userid="1" > <xbobdefine findall="false" >

Need an if statement? BobX has you covered.

<xbobif condition="amount <= 12" > ...Some HTML here... <xbobendif>

Need more than one condition tested? Easy. Just nest your xbobif statements and you're in business!

After three days of churning through his "easy" task, Christian was bleary eyed and exhausted. He spent an entire afternoon tracing a HTTP 500 server error down to a particular xbobdefine statement (BobX was very whitespace sensitive as it turned out), and out of frustration, typed <?php phpinfo(); ?> into a BobX script. When he ran it in his browser, he was amazed to see the server's PHP configuration appear before his eyes.

A Dastardly Plan

Christian came to learn that BobX was, in fact, written in PHP. A parser written in a parser, BobX did a great job at hiding its underlying platform. When Christian tried adding normal PHP code to a BobX script (such as echo "hello world";), he would receive a xboberrorcode 59:INVALID FUNCTION CALL FOUND. It was only when he had a single function in the first <?php ... > block that it seemed to do anything PHP-related.

Armed with this knowledge Christian hatched a plan. Rather than code up his solution in BobX, Christian wrote a simple function to allow the injection of his PHP code. When he ran the form, it worked! Now excited that he had finally defeated BobX, Christian tried out his theory on other web screens - they worked too! Weeks passed and Christian started plowing through assignments earning accolades from management and users started to take notice too - even the most complicated apps were taking seconds instead of minutes to load.

Overjoyed with his newfound energy and motivation, Christian decided to come clean about his workaround and started penning up a summary for his supervisor, however, as fate would have it, soon after starting, Christian's boss Brian appeared at his desk, sweaty, red faced, and obviously fuming mad. He breathed a few times to lower his color and asked, "I received an email from Bob. He says you hacked the production server, did you?" This was definitely not the reaction that Christian expected.

Christian did his best to explain the method and how it could simplify things, but it was no good. Apparently, Bob was hopping mad, reporting that not only had his server been compromised, but also to throw acid on the situation, he threatened to pull out of his contract, taking his servers, infrastructure, and know-how with him. In the end, cooler heads prevailed when Bob and Brian struck a deal - if the code would be reversed to pure BobX, all would be as it was.

Christian's marching orders were to revert the code back to the way it was previous to his starting at his job and then re-implement his 'hacked' code in BobX. ASAP.

Ultimately, Christian complied with the first part quickly, but decided that his best option might be to call it quits, and join the ranks of developers who just couldn’t keep up with BobX.

Remi works on one of his country's largest Internet Service Providers, and has the fortune to be on an elite team that focuses on agile development. Or misfortune, depending on how you look at it: at his company, "agile development" actually means "we need that in two weeks".

One of Remi's first assignments was to fix an "emergency" on one of the ATM Addressing systems. Apparently, the application was coming up with incorrect routing data. After a solid day-and-a-half of digging through Visual Basic code that called SQL Server stored procedures which called VB-based COM objects which called more stored procs, Remi found a weird table ("Cal_ATM") that was referenced from an externally-linked database, and the data in that table was completely out of date.

Wondering how that table was populated, Remi searched high-and-low through the VB and stored proc code, but found nothing. Thinking it might be directly updated by some batch job, he looked through the job lists, and that's where he found it: a step buried in a job that called "EXECUTE PUpd_Cal_ATM". As it turned out, the step had been erroring-out for nearly a month-and-a-half with "Could not find stored procedure PUpd_Cal_ATM". No one knew about it, of course, because the failure notification was also not working.

The timing of the failures seemed to coincide with a recent "emergency" clean-up effort that another developer on the agile development team performed, and Remi was worried that this procedure was accidently deleted during the clean-up. He searched for a backup that was made before the clean-up project, and was able to restore the missing procedure. Its entire code was as follows.

CREATE PROCEDURE [dbo].[PUpd_Cal_ATM] AS -- +---------------------------------------------------------------------------+ -- | Description : Feeds the tables ATM | -- | Entry : none | -- | Output : Return (0 = OK) | -- +--------+------+-------+---------------------------------------------------+ -- | Date |Author|Version|Description | -- +--------+------+-------+---------------------------------------------------+ -- |06/12/07| XXX | 1.0 | Starting version | -- +--------+------+-------+---------------------------------------------------+ -- For now, this stored procedure is empty but it may be -- called by UpdateDatabase -- ========================================================================== -- return code -- ==========================================================================

It made little sense; this procedure had clearly not been feeding the database for three years, yet the data was only a week old. It took him three more full days to figure out the source: a hotfix to Microsoft Office caused a certain type of macro code in Excel to be considered insecure, and a certain type of macro was being used to feed the ATM Addressing system from Excel.

Oh, the joys of agile development.

Chas Ryder writes, "false... fish... yeah, I get those mixed up all the time."

 

"I was doing some research on managed hosting providers," writes Chris T., "Liquid Hosting had me sold until I found this."

 

"I got this message when attempting to open Greetings Workshop after a RAM upgrade," notes Robert Pendell

 

"I was having some issues with my UPS, so looked on the back to see if there was anything helpful," writes Eric B, "other than being reminded that there was a Risk of Shock three times, I was also told to refer to the bottom of the UPS."

 

"The 'waiting room' for a website checkout at Royal Albert Hall is a bit disconcerting," Martin Mortensen writes, "and their message isn't very helpful, either."

 

"Someone put a 'Tip of the Day' feature in one of our in-house applications," notes Jan Srzednicki, "it never really expanded beyond this tip, though."

 

Reuven was greeted with this message when an installer crashed on his PC.

 

"Not that it matters," writes Aaron, "it's probably password-protected anyway."

 

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 to 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!"

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."