Although the company was relatively small (about twenty people in total), the pay was very reasonable and it was exactly the position that Victor was looking for a web developer with a tiny bit of network administration on the side. His first day was pretty normal as far as first days go — paperwork, acclimation, source code setup, etc — and he even got a friendly text message from John on his way home from work.

Hey Vic, glad to have u on 
board! How is everything 
coming along?

Victor felt it was a nice gesture and responded in kind.

Hi John, thx for asking. So 
far, so good! Got good start 
on things in 1 day. Have a 
great night, c u in the AM!

Thinking nothing more of it, Victor was surpised to see another message from his boss.

Good to see. So what did u
get done today?

Nothing wrong with some chit-chatting, Victor thought to himself, it's good relationship building! He responded back.

Aside from paperwork, got 
the codebase downloaded and
running; also started to
look at the buffer issue.

And then another text came from John.

Nice. U take any breaks thru
the day?

Before Victor could even formulate a response, another message zipped in.

I mean, good to take breaks
and all. Do u find you made
good use of your time?

Victor was a bit taken aback by the messages and carefully crafted a response.

Agreed. I think I struck a 
good balance today.

Over the next hour and a half, the messaging continued. John quizzed Victor on almost every aspect of his day, from what he thought of the current codebase to whether he had thought of a solution for the buffer bug. And then he requested that Victor install an Instant Messanger client on the admin’s workstation. There was a good forty back-and-forth messages that evening, ending with Victor’s at around 8:00PM.

Well, I'm off to dinner with
the family. We'll catch up 
in the morning. G night!

As Victor was leaving for work the next morning, he looked at his phone for the first time since dinner the previous night and found twelve new messages in his inbox. They were all from John, and started with a simple question.

Hey, so do you think we can
set up a new virtual server
for testing 64 bit?

The next few messages were a simple follow-ups.

Get msg about 64 bit srv?

Dunno, could be worth doing?

Hey, u there?

The next few messages got progressively more unbalanced.

anyone there?

how come ure not replying?

what are you dooooing?

finish dinner yet???

They crescendoed to the final message of the night.

Have you run away?

Victor was hoping — nay, praying — that John had a truly strange sense of humor. His hopes were quickly quashed the moment his phone rang. It was John.

“Vic, buddy,” John said in a relieved tone, “where have ya been? I was up all night fretting! You can’t just disappear like that!”

In retrospect, Victor should have responded with a restraining order. But alas, it was his first job and he didn’t want to lose it on his second day. He tried explaining to John that he had gone out to dinner, shut his phone off, and then came home and went to bed.

“Of course,” John said in an agreeable tone. “We really value communication here, and you’ll need to restructure some of your home time to accommodate the needs of the company.”

Again in retrospect, there were a lot of things that Victor should have said, but he said he’d try his best. Victor added, “in the future, just ‘check out’ with me before going to bed for the night, and to ‘check in’ when I got up in the morning. I mean, I’d hate to wake you up!”

Fortunately, the night-time messaging mostly died down after that, though it was replaced with even more bizarre behavior. During the day, John would “make his rounds” a few times each hour, which consisted of him going to each and everyone’s desk to get a status update. It was never in a harsh, why-aren’t-you-done-yet manner; it was more need-to-know-every-detail-about-everything and keep-up-the-great-work.

Leaving — whether for lunch or at the end of the day — almost always prompted the same response for John: “now don’t forget to come back!” To the casual observer, such a statement could easily be mistaken for a mild joke, but Victor was convinced that he was sincere. On several occasions, John asked Victor if he was “planning to run away.”

It may have taken a couple months, but Victor eventually did run away. Far, far away. And he never looked back.

<!-- -->

The Daily WTF Sponsors
		Microsoft WebsiteSpark - a great program for web shops and freelance web developers and designers where you get some great software (Visual Studio Pro, SQL Server, Server 2008, etc), at no upfront cost for three years; it also provides support and resources to help grow business
		Rackspace Cloud - massively scalable hosting for .NET (2,3,3.5) PHP, Ruby, etc., with unlimited sites & mailboxes, simple online provisioning, and an enterprise clustered platform that's supported by real people.
		Peer 1 - provides award-winning Managed Hosting, Dedicated Hosting, Co-location, and Network services offered through 15 data center across North America. With over 10,000 businesses hosted on their legendary SuperNetwork™backbone, PEER 1 delivers one of the highest server performance and network outputs in the industry.
		MindFusion - a great source for flow-charting and diagramming components for a variety of platforms including .NET, WPF, ActiveX and Swing
		Software Verification - software engineering tools for memory leak detection, code coverage, performance profiling, thread lock contention analysis and thread deadlock detection, flow tracing and application replay on the Windows Vista, 2003, XP, 2000 and NT platforms.
		Atlassian - the folks behind JIRA (which, in turn inspired Manual JIRA) wanted to let you know that they're not a "follow the rules" software company who realizes that there is no single recipe for practicing agile development. They were once hungry for practical tips, so they thought they should share their agile story.
		SoftLayer - serious hosting provider with datacenters in three cities (Dallas, Seattle, DC) that has plans designed to scale from a single, dedicated server to your own virtual data center (complete with racks and all)
		SlickEdit - makers of that very-impressive code editor and some pretty neat Eclipse and VisualStudio.NET tools and add-ins, some of which (Gadgets) are free. Check out this short video highlighting just one of SlickEdit's Visual Studio integration features.
		SPN_NAME - TODO

And now, back to our regularly, completely off-topic scheduled program.

"There is something so fundamentally wrong with this," David Daniel notes, "I bought an 'eBook' from the Arizona State University bookstore. At checkout, I wondered why they wanted me to choose a 'shipping address' and a 'carrier'... and now I know. They FedEx'ed me the eBook."

Carlos Santander spotted this at one of the rooms in the New Yorker Hotel in New York City.

Sam Ashmore writes, "I came home one day after they 'upgraded' the cable, and I found this."

"I found this graffiti on a wall," Marco writes, "I guess some people really couldn't deal with the move to NTFS?"

"I found this 'jack battery' at a friend's flat," writes Martin Haimberger, "the cable which comes out of the wall supplies them all! What a great engineer."

"I don't really know where to put a red frame to mark the spot," Norbert writes, "maybe around the whole picture?"

view entire box

"We told you our Optional ROM Placement setting was risky," Hae Yu writes, "but did you believe us? Noooo!"

Chris writes, "I think they forgot something."

"Waitaminute," writes Ryan Blace, "so how am I supposed to get in?"

"It might have been helpful to have an instruction to 'read page 61 first' on the front of the manual," writes Paul Webb

"I was a bit confused when I saw the price difference on the two Leo bars," Wouter Verhelst commented, "needless to say, I went for number 51."

"When the soap runs out," Hans Holmberg wonders, "where are you supposed to download more?"

And when I say the money goes towards these projects, I mean all of it. 100%. We pay for all expenses — PayPal fees, material costs, postage, etc. — out of pocket. But speaking of money, I’m happy to announce that we’ve raised $3,630.50 and are mailing out checks to the appropriate projects today.

Why Inedo? We're still in the process of starting an official not-for-profit. TRWTF is how much work that takes to do!

There are currently five projects supported, two of which — Drupal and FreeBSD — were added as a result of your feedback. The donations break down as follows, with Drupal and FreeBSD getting revenue from those who said "Let the Alliance decide" where their contribution goes.

Apache	$803.00
jQuery	$1,500.50
Postgres	$288.50
Drupal	$288.50
FreeBSD	$500.00

Now if you do the math, you'll notice that the sum of the checks is $250.00 less than the cash received. There's a good reason for that.

Announcing The $500 Good Code Grant

Obviously, we're not expecting to change the world with $500. We'd just like to start or help something that maybe — just maybe — could make the world of code a better place. Here's how the grant works.

Tell us how your free and open source project prevents bad code from being created and show us how $500 would make a real difference in your project
— or —
Propose a new, free and open source project and show us how $500 would help you get it started

Will it work? I think it could. The folks like John Resig who dedicate their nights and weekends to creating projects like jQuery have it hard enough developing their project code. Then they have to recruit other developers, write unit tests, create documentation, and so on. And then they have to pay real money, out of their own pocket, for things like hosting, logos, and hardware.

Imagine that: all that meta-work and expense just to do work to build something that'll be free?! I think the least we can do is help with the expenses, and that's what we, The Alliance for Code Excellence, hope grants like this can achieve.

Join the Alliance for Code Excellence

When we chose the name the Alliance for Code Excellence, it was somewhat tongue-in-cheek, to fit with the satirically pompous copy on the Bad Code Offsets site. Well that, and Jeff already called dibs on the superhero theme with the whole League of (web) Justice thing.

That said, we don't want to come across as actually being pompous. Because we're not. We're simply a group of colleagues who want to improve the state of software development industry, whether it's through Bad Code Offsets, Good Code Grants, or whatever. And we're not even exclusive; in fact, we'd love it for you to join us.

The Alliance for Code Excellence is a not-for-profit venture that's 100% volunteer driven. But we do have some real costs, such as legal fees (a 501(c)3 is not quite DIY), materials costs (printing Bad Code Offset certificates), postage (especially for the overseas orders), and so on. The costs are paid by the Alliance, not through Bad Code Offsets.

So if you like what we do, feel free to become a member. A one-year membership is $50 and, as a welcoming gift, you'll receive a black T-shirt with our logo on it.

Become a Patron Member Cost: $50.00 Select T-Shirt Size: Small Medium Large X-Large XX-Large XXX-Large

Don't get me wrong: $50 isn't chump change and, quite honestly, you can buy several cool T-shirts for that. But it's not about the shirt, it's about joining the team and doing what we do: spending hard-earned money and precious time to build a better tomorrow, one line of code at a time.

If you purchased Bad Code Offsets, you should be receiving your certificate(s) in the mail in the next few weeks. We're a bit behind, but will get them out as soon as possible.

“Err,” the receptionist nervously answers, “there’s a… err, delivery for you, sir. They—”

“Hmphf,” Brad’s scoff cut her off. “So just sign for it, then! Is that really that hard to do? You can do that, can’t you?”

“Well sir,” the receptionist winced, “they’re asking for mooring instructions? And we need to pay wharfage charges? They said you’d know. I’m at a loss.”

“Fine,” Brad scowled, “I guess I have to do everything around here!” He slammed down the phone and marched out of his corner office. Despite Æxecor’s location – the “old docks” district – their office was one of the most posh in the city. On one end of the expansive, former warehouse sat the executive suites, which had a tremendous view of the city skyline. The other end – where Brad was headed towards – was the reception which overlooked its own, private bay on the river.

“Okay, I’m here!” he angrily announced once he stepped foot in the lobby. “So let’s do this! What do I need to—”

Brad stopped mid-sentence. His eyes were immediately drawn through the floor-to-ceiling windows and onto the river bay that Æxecor’s building overlooked. There was an absolutely gigantic barge – nay, an armada of tightly-connected barges – overfilled with enormous piles of coal that was attempting to dock in front of the building. “What… the… fuuu—”

“You mus’ be Brad,” a cheerful voice jumped in. Brad’s eye’s shifted towards the scruffy fellow wearing some sort of workman’s uniform who was sitting in one of the reception chairs. “Now first and foremost, how in the Sam Hill are we ‘sposed to moor this boat? I count two cleats, but we sure as heck can’t hitch these. And, shoot, do you even have a bulk berth?”

For once, Brad was speechless. He had absolutely no idea who that man was and he could hardly understand a word he said. Plus, there was that gargantuan vessel that was slowly moving towards the building. “Uhh,” he stuttered, “wait. Are you delivering… coal? To… uhh, us?”

“Well, yeah! Twenty-eight thousand tons of the good ol’ black gold!” The workman sarcastically furrowed his brow adding, “I mean, we did get the right address, har har. This is Æxecor? And this is Pier 53? And you are Brad, the fella who ordered it, right?”

It was that moment that Brad’s palm almost immediately made contact with his forehead. He realized that something must have really gone awry: instead of virtually trading 28,000 tons of coal, Brad had somehow ended up with 28,000 tons of real coal.

Commodity Futures Trading 101

If you’ve ever watched Trading Places, the 1983 classic starring Eddie Murphy and Dan Aykroyd, then you’re probably at least familiar with commodities markets. At a basic level, commodities such as gold, wool, and soy beans are sold by producers and, eventually, delivered to buyers. But Billy Ray Valentine didn’t strike it rich and bankrupt the Duke Brothers by hauling around Frozen Concentrated Orange Juice (FCOJ); instead, they worked the commodities market by buying and selling FCOJ futures contracts. Actually, that’s really the only way to trade in commodities.

A futures contract is pretty straight forward: you agree to buy X units of commodity Y at $N per unit at some fixed future date. While it might seem a bit strange for an individual to agree to buy twenty tons of pork bellies in April for $34,420 (even if he really loves bacon), the idea is to sell the to-be-delivered pork bellies long before April, and to sell them for more than $34,420. Just about every conceivable commodity is bought and sold in this manner long before the commodity is even produced. The whole point of all this trading is to shift the risk (and rewards) of fluctuating commodity prices from the producers (farmers, miners, etc) to the traders.

Of course, because commodity traders don’t actually want to be stuck with tons and tons of pork bellies, a whole series of middlemen — from the brokers to the exchanges to the clearing houses — work hard to ensure that, when you say "I’ll buy 300 tons of pork bellies for $518,000 in May," you don’t actually buy 300 tons of pork bellies for $518,000 in May.

Brokers, for example, will set up round-turn trades so that, for each futures contract purchased, an offsetting contract can be sold to whoever actually wants to buy the goods. The exchange’s automated trading systems have all sorts of rules-engines to make sure that obvious errors (like delivering truckloads of commodities to a commercial office park) don’t slip through. And finally, processors at the clearing house will double-check transactions to make sure they weren’t sent over in error.

All that said, it’s almost impossible for traders to actually buy the commodities they are buying. Well, almost impossible.

A Perfect Storm

Æxecor traded coal on only one exchange (the WTFSE), and they didn’t trade coal very often. As such, when WTFSE upgraded its public-facing, WebService-based API, Æxecor’s internal trading system could no longer communicate with it. With a couple pending coal trades, this presented a bit of a problem.

Fortunately, Æxecor had a staff of crack programmers, and they were able to hack together a solution that worked with the WTFSE’s new API. Essentially, the coder added a bit of XML to their trading requests, including this following snippet.

<AdditionalProperties>
   <PhysicallyDeliver>
      <value>False</value>
   </PhysicallyDeliver>
</AdditionalProperties>

Notice anything off about that XML? If you said, “value should be 0 instead of False”, then give yourself a pat on the back. As it turned out, WTFSE only recognized 1’s and 0’s to represent True and False and, if the value was nether 1 nor 0, it simply defaulted to 1. Whoops!

Now, this normally wouldn’t have been that big of a deal; to ensure accurate transactions, the WTFSE (and just about all other exchanges) sends back a trade confirmation with all of the original information encoded in their XML. That way, both parties have to understand each other’s data. On Æxecor's end, everything looked hunky dory, especially as a result of the following line of code.

bool physicallyDeliver = 
    (getNodeVal("PhysicallyDeliver").toLower() == "true");

Kudos to the developer for verifying the correct case... but, a string can be infinitely more things than simply "true" or "false". Such as "1" or "0". Whoops.

Even a mistakenly confirmed incorrect trade shouldn’t have been that big of a deal, since the clearing house would notice some pretty big problems with the trade. You can’t just call up FedEx and request delivery of thousands upon thousands of tons of raw material to some office complex downtown. Commodities can only be delivered to a fixed number of delivery points, such as warehouses adjacent to train yards or ports. Of course, since Æxecor’s offices were in located on Pier 53, a recently redeveloped warehouse district off the river, it would have seemed like the logical place to accept delivery of a whole bunch of coal, especially to a rules engine. Whoops.

Fortunately, the commodity futures trading market doesn’t rely entirely on software. There are back-office personnel on both sides of the transaction (and several places in the middle) to make sure that a trader doesn’t do something silly like accidently click the “physically deliver” checkbox, enter into round-turn trades that creates an instant net loss, and so on.

So with everyone looking over transactions, you’d think that someone along the way would have noticed that trading giant Æxecor asked for physical delivery of a million-and-a-half dollars worth of coal. Actually, someone probably did, but because the trade came from Brad, there was just no way it could be made in err.

As the senior trader at Æxecor, Brad made it very clear that no one — “not even His Holiness, the Pope” — shall question his trades. After all, Brad makes complex trading decisions that no one else could possibly comprehend. Sometimes he buys high and sells low. Sometimes he holds in a decline. Sometimes he refuses to sell at any price. Brad works in mysterious ways, and if he said “do it”, then it better get done.

An Early Christmas

“Now don’t go telling me that this coal ain’t yours,” the workman said defensively, sensing something was awry. “I mean, if you don’t want it, that’s your business. But this here is your coal, mister Brad.”

As much as Brad wanted to deny it, he knew it was his. And not only that, but he had haughtily confirmed, re-confirmed, and re-re-confirmed with Æxecor’s own back-office processing team. He had just assumed, like he always did, that the mouth-breathing paper-pushers couldn’t read English. As he played back the last thing he told one of the processors about the coal order – “what part of ‘execute my f*ing trade’ don’t you understand!?” – he wondered what he could possibly do with 56,000,000 pounds of real coal.

Try to imagine for a moment how you would unload a mountain of coal worth million-and-a-half dollars. Craigslist does have its limits, after all.

As it turned out, it was more difficult than Brad could have ever imagined to sell real coal. The commodities market really only deals in futures, and everyone who actually needs 28,000 tons of coal has bought it long in advance. And besides, who wants to buy coal from some guy named Brad? Eventually, after paying exorbitant wharfing, shipping, environmental, docking, unloading, loading, and multiple-fee fees, Brad was finally able to unload it for twenty cents on the dollar.

Ever since “The Big Purchase”, Brad has never been able to live down his mountain of coal. Every time he passed others in the hallway, he knew that they knew about the coal, and they knew that he knew that they knew. No one really poked fun or laughed at him, but it didn’t matter. Brad was no longer thought of the senior trader at Æxecor; instead, he was the guy who accidently bought all that coal.

Daren S knew that his days were numbered. He was a troublemaker bent on changing The Way Things Were and The Director was hot on his tail. Though Daren worked discreetly, improving his coworkers' productivity a little bit at a time, it only was inevitable that The Director would eventually find out. One does not become The Director by letting such things slide.

A financial services provider, Daren's company did a lot of data processing and aggregation from a lot of different sources. The Director acknowledged that their processes were "a little rough around the edges" but insisted that they ran "smooth, like a factory." An accurate analogy I'd say, especially considering what the typical industrial factory is like: poisonous steam pipes spewing death gas every three seconds; razor-sharp pinwheel governors spinning at different yet predictable intervals; and giant, spiked stampers slamming down on conveyer belts running different speeds in varying direction, all placed inconveniently at the entrance and exit so that they must be meticulously navigated to avoid a significant loss of Life Points. At least, that's what every factory I've been in was like.

Also like a factory, the company's processes were developed over several years by many different engineers who carelessly bolted additions to the diabolical machinery. The most convoluted of these processes was the bi-weekly Hedge Report. One of the business' most critical reports, it took two people two full days to create. It was also Daren's new maintenance responsibility and, consequently, his downfall.

The Hedge Report needed data from four different sources aggregated into a single SQL Server. The aggregation was entirely manual: spreadsheets were generated, copy/pasted to each other, emailed, processed with a special script, emailed again, and so on. Daren's first mistake was to create a Visio diagram that modeled this process. Everyone knew how it worked, so said The Director, and Daren could have just asked any one of the many people involved.

Daren's second mistake was to make a minor change to a VB5 application that extracted data from another SQL Server. Before his change, the application would inform its user of a null datum by crashing and leaving a half-processed file that required the user to dig through, go back to the original SQL Server source, and change the null datum to the string "NULL."  Though it shaved a few hours off of the report generation time, The Director felt it was a waste of time, because they had a completely suitable workaround.

Daren's third mistake would have been his suggestion to change an AppleScript that processed semi-raw data to a more manageable VBScript. But he was starting to learn. Although this AppleScript required that someone at another location logon to the company's only Mac workstation, run the script, and email back the results, Daren figured this would be a battle for a much later day.

Sadly, Daren never got to fight that battle. Fed up by Daren's constant requests to "improve" the process, The Director demanded to know what <em>exactly</em> was wrong with the ASP.NET module that Daren kept asking to change. After all, he personally oversaw the addition and paid good money on consultants to build it.

Daren printed out the Page_Load() method using a half-spaced six-point font with two "screens" per page. He highlighted the buggy and incorrect code, spliced the pages together, and went back to The Director's office. In a move that may not have been the wisest career choice, Daren held the first page in the air above his head and let the other taped-together pages cascade to the floor. With over seven-feet of highlighted code in hand, Daren said: "this is what's wrong with the code."

Over time, the ISP grew in size to sell additional products such as new domain types and packages with a multitude of sub-products. Also, as the system grew in size, the site began running slower and slower. This gave Simon a reason to look into ways to improve the efficiency of the shopping basket and invoicing parts of the system.

However, the more familiar Simon got with the code, the harder it was for him to understand why it was allowed to remain in place for over ten years.

Elseif()s EVERYWHERE!

They say it takes an entire village to raise a child, but Simon discovered that it took over 16,000 lines of code to process the sale or print an invoice.

How could something like this be? The answer was surprisingly simple. As the company grew, it was simple to add new products. Just add a record to the master product table in the database and then add a new "elseif()" block to the shared code. Same thing went for discounts - toss in another elseif(). T-Shirts? Another elseif()...and so on so that the code was almost entirely made up of hundreds elseif blocks, each of which would need to be evaluated whenever a customer would add or remove an item from their shopping cart. Also, a side-effect of this design was that if someone wanted to change a product's description, for example, they couldn't just edit the database record, they would have to create a new product code and leave the old one in place forever.

Simon figured, My work's cut out for me - it should be easy to improve performance! Just trim out the elseif() blocks for the old items and discounts and I'm done! Ordinarily, Simon's reasoning would be absolutely correct, however, there was a small snag in this plan in the form of several hundred dire warnings.

¡NO TOCAR!

In looking for candidate code to trim, Simon found that most elseif() blocks heeded the warning DO NOT REMOVE and DON'T TOUCH UNDER PENALTY OF DEATH and the like, just like the following:

// xmas offer 20071206 - 20080103 DO NOT REMOVE, EVER!!
if($rowval['orderitemref'] > 10295755 &&  $rowval['orderitemref'] < 10373106 && (
    (substr($rowval['domainname'], -3, 3) == "com") ||
    (substr($rowval['domainname'], -3, 3) == "net") ||
    (substr($rowval['domainname'], -3, 3) == "org") ||
    (substr($rowval['domainname'], -3, 3) == "biz"))) {
       $thestr.='<font face="arial,verdana,helvetica" '
         .'size="-2" color="#ff0000"> at special offer price.'
	 .'<br>Renewal at standard price</font><br>';
}

The reason for this was also simple - as new items, price changes and special offers had come and gone over the years, it had exposed the problem of how the system handles historical invoicing. You see, the important thing about invoices is that they must be immutable. If a customer called up to argue a charge from six months ago, customer service had better be able to pull up that same invoice and it had better match what the customer saw at the time.

What Simon needed was a brilliant plan.

The Brilliant Plan

Simon figured he had two options in trying to bring down his goliath. The first option was to refactor the 16,000 lines into a system that would be able to regenerate ten years of invoices flawlessly and spend the rest of his life regression testing while in the meantime, the number of elseif() blocks would inevitably grow.

Alternatively, he could take the quick, dirty, and simple route: print out the historical invoices so that the CSRs could pull up when needed. Well, not print on real paper, but rather batches of PDFs of every historical invoice. This would allow him to simply ditch the old code entirely.

Simon was immensely proud of this solution and presented the idea to management. "Why would we want to change," his boss rhetorically asked, "what we have works already and has been working consistently for the past ten years!"

Defeated, Simon went back to his maintenance work and added yet another elseif() block to represent yet another promo offer.

When I tell people that, they often scoff and offer replies like “so you’re not a programmer then?” and “let me guess, you’re a coding deity or something?” Well let me say, I am a programmer and I am not Codethulu, but in the same manner that Al Gore can fly around the world in a private jet without polluting, I have negated my bad code footprint through the purchase of Bad Code Offsets.

This is all made possible through the Alliance for Code Excellence, a group for which I am proud to be the chairman. Its charter members include Jeff Atwood, Erik Sink, Jon Skeet, Jason Cohen, and several other software development community leaders who are just as passionate about quality code as I am. We stand strong with our vision:

We envision a world where software runs cleanly and correctly as it simplifies, enhances and enriches our day to day work and home lives. Mitigating the scope and negative impact of bad code on our jobs, our lives and our world is our all–consuming passion. We foresee a time when bad coding practices and their rotten fruits have been eliminated from this earth and its server farms thereby heralding a new age of software brilliance and efficacy.

Nettlesome bugs and poorly written code have been constant impediments towards realizing our full potential as programmers and engineers. Bad Code Offsets provides the vehicle for balancing the scales of poor past practice while freeing us to pursue current excellence in code development. Until the dawn of the worldwide, bug free code base, each of us can take steps towards reducing our bad code footprint and remediate the bad code that we have each individually and collectively left behind on the desktops, servers and mainframes at school, at work and at home.

While the notion of offsetting bad code instead of outright correcting it may seem like a "hack" to some, we believe it's a good approach for today's problems and today's codebase. The dollars you spend purchasing Bad Code Offsets are donated to various worthy Open Source initiatives that are carrying the fight against bad code on a daily basis. These organizations currently include jQuery, PostgreSQL, and The Apache Software Foundation.

Building a better tomorrow—one line of code at a time

Imagine a world without bugs. Not the creepy-crawly-soil-enriching bugs, more the bugs that plague all software, past and present. The bugs behind the inane error messages you see day-in and day-out. The bugs that cause multi-million dollar business disasters. The bugs responsible for (literally) crashing billion-dollar space exploration equipment.

By today’s coding standards, a world free of bugs is a far-fetched fantasy. Bugs are an ever-present part of code and about as likely as a semi-colon in a C++ program. But does it always have to be like this? Will there always have to be bad software?

While I do believe that, one day, given sufficient tools, knowledge, and experience, we achieve the worldwide, bug-free codebase, there’s a preposterous amount of work and clean-up between here and there. Think of the swaths of bad code that we have left behind on the desktops, servers and mainframes at school, at work and at home. Add to that the bad code that is being churned out each day by unskilled colleagues and our own laziness, and we're left with a completely unwinnable battle.

That is, unless we try a radically different approach. And that's exactly what we're doing with Bad Code Offsets. It's our first, bold step towards universal code excellence.

Why Bad Code Offsets? Why Now?

Not many things in life allow us to atone for past mistakes. But by buying Bad Code Offsets, you can not only do that, but you can make up for other people's mistakes. Get them for your friends, for your peers, and of course for your code review sessions.

They're inexpensive (50¢ per SLOC) and come in a number of denominations. Plus, for a limited time, shipping is free. Buy as little (minimum of 3) or as many as you'd like.

Tonight Only: Code Offsets at the Conga Room in Los Angeles

If you're in the SoCal region this evening (Wednesday, November 18), make sure to stop by the world famous Conga Room. We'll be officially launching Bad Code Offsets at the Underground @ PDC 2009 event (free, but registration required) in Los Angeles. Pick up some Daily WTF stickers, Stack Overflow stickers, and of course, your very first Bad Code Offset.

Today was no ordinary day. He was in the hot seat, presenting to the Software Advisory Committee - a multi-disciplinary group responsible for rubber stamping any and all new production application installations at MegaBank.

Much like being presented before a village's Council of Elders, if he received their blessing, he would no longer be considered among the ranks of MegaBank’s junior developers. Instead he would be shoulder-to-shoulder with the man developers in the company.

His word would have weight. People would come to him for advice, but all this could be demolished if he did not gain the thumbs up of the Committee who was headed up by Michael’s manager, Greg.

"Why can't we give the user their password in the e-mail?" Greg asked, in the same tone of voice you might expect if someone had told you they couldn't eat their soup because the spoon was upside down.

"I go on websites all the time and they always tell me my password when I forget it!"

For a moment, Michael thought about asking "which websites?". He also considered burying his face into his palms, or perhaps bang his forehead against the desk repeatedly - anything to get the stupid the development manager was spouting out of his mouth.

However, if Michael had even the remotest of hopes in getting his first new application installed, he was going to have to play this one cool.

Life at MegaBank is not without its shortage of WTFs: there is a global variable used in three different ways (depending on what part of the code is running) within the same module, one method is called by sending the sequence of keyboard presses that select and then press a button, and then of course there are the never-ending chains of if-statements nested so deeply you'd need a grappling hook to climb out.

However, none of these could touch the WTFness of the Software Advisory Committee meetings. To fully grasp what this is like, imagine you have two bosses who work in alternating schedules, and each despises the decisions that the other makes. Now imagine those two bosses are the same person – this was the committee of Greg.

In these meetings, Greg would incredulously ask why the developers would dare even suggesting that they may try to implement the features he had told them to implement several weeks ago, and Michael’s session with the committee wasn’t going much better.

“The only thing that sending a user a gobbledygook URL instead their actual password accomplishes is proves that we are a company of sloppy and inexperienced coders. In the end, you’ll be turning customers away from us balking at our utter lack of professionalism!” Greg explained.

Michael tried to make a case by saying that the email that went out did not show a full URL but rather it wassafely behind a link labeled “Click Here”  Also, the process of picking out a new password was actually quite friendly. However, there was no chance to begin reasoning.

Greg lowered the brim of his glasses further down his nose for emphasis. “The standard way of recovering passwords is to send a user their password, not to hide it behind a link! Here, let me show you how Google does things – pay attention and please, keep an open mind.”

While Greg surfed onto Gmail to go about resetting his password, Michael could barely watch – the embarrassment was too great. He thought that he had considered every angle and that he here he was going to be proved out to be a fool. However, he was saved at that last minute.

In the email that Greg had received, Gmail sent a link enabling him to set a new password.

We're in a bit of a jam, an email to the support desk read, we accidentally ran an entire day's worth of transactions for 11 Oct 2009 instead of 11 Oct 2006. Can you fix this?

In the world of retail, it's not an uncommon practice to "open" for a business date that is not the current date. Think of 24-hour stores that want to "close" the day at 11:00 PM instead of midnight, or the cases when the registers are out of commission. Whatever the reason, it's a feature that customers want and a feature that T. Ferguson's company provides in their point-of-sale systems.

Obviously, there's no way for the software to know if a different date is purposeful or accidental; all it can do is default the "open" date to the current date and hope that someone would notice a mistake on the registers, receipts, etc. before the day was "closed" out. The support email was the first "problem" that T.'s company had with this feature since first offering fifteen years ago.

Despite having a nation-wide chain of stores, with each bringing in nearly $500,000/day in sales, this company decided not to go for the extended-hours support contract. With no one to call at 9:30 PM for support, the shift manager ignored the incorrect date and "closed out" the store's point-of-sale system. He left a note for the general manager, who promptly emailed support the next morning.

The general manager also called the support line at 9:01 AM -- just after it opened -- to make sure they got the email. He was very concerned that the error would gravely impact their October reports, forecasting reports, inventory, and just about anything else that relied on that day's transactional data. The support rep assured the general manager that the development team was working on a way to fix the issue.

From a programming perspective, this was actually an easy thing to fix. All of the daily transactions are stored in a single database table, so a simple UPDATE script and a "re-close" should do the trick. They reproduced the "problem" on a test machine, ran the fix script, and watched it worked like a charm. T. called up the store to let the manager know how they planned to resolve the issue.

"But," the manager asked, "what about when someone makes a return? Their printed receipt will have a different transaction date. Won't the register refuse the return?"

"Nope," T. replied, "we only use the store number, register number, and transaction number when we validate the receipts for returns."

"Sounds great," the manager said in a much less stressful tone, "what a relief! I was really worried about how bad this would be."

The fix was sent to a technician to fix the problem on site. Before running the script, he noticed one thing that the development team missed: not only was there only one day of faulty data in the database, there was only one day. Period. All the transactional history was gone!

That, of course, would present a problem when trying to process a return. Or receiving merchandise that was ordered in the past. Or verifying an employee's time clock punches. Or tracking special-ordered items. Or knowing whether the store is on pace to meet its weekly sales goal. Or just about any activity of any consequence in retail that ISN'T selling merchandise.

The technician reported this back to the development team. After a bit of digging, they figured out why only the one day of data was left: part of the register closing code purges data that's over three years old. And how does one find three-year old data when the system clock is not a reliable indicator? Why, by taking the business date of the newest transaction and subtracting three years, of course!

The manager's day was about to get much, much worse.
 

A few years ago, Phil was working as a developer on a wire transfer application at a large bank. To make sure that nothing technical would prevent the bank from extracting maximum amounts of money from its operations, every part of their system had a redundancy with fast failovers and clustering. In fact, there was even one server (and a backup of that server) whose only function was to monitor the other server and send notifications if anything fell out of the operations norm.

When a system or process failed, the monitoring server would page the on-call support administrator, who would then log in and restore the errant system to its rightful state. On rare occasions, an actual visit to the server room was required.

One summer day, at about two in the morning, the on-call administrator (Mark) was awakened with a Critical Notification Alert that a couple of core processes -- such as the ACH Batch Script and General Ledger Job -- had crashed. Moments later, he was paged again, this time with notification that the fail-over processes had failed.

As Mark attempted to log in to the process control cluster, he received another Critical Notification Alert. And then another. And then several more. The remote access server wasn't responding to his log-in attempts, so Mark got dressed and headed downtown.

About halfway to work, his pager stopped receiving alerts altogether. That was a pretty bad sign, so he dialed into the office to access the company directory and get the numbers of secondary on-call administrators. But the phone lines were dead, too, which could only mean one thing: a bomb, a fire, or a giant robot wreaking havoc throughout the city.

When Mark arrived at work, things were very quiet. He nodded at the security guard and took the elevator to the server room. Mark approached the server room and saw that the automatic secure doors were propped open. As he entered the room, Mark felt a blast of heat and noticed two maintenance employees, both sweating profusely, working on the air conditioner units. This seemed a little strange since Mark should have been the one to call the maintenance crew out there, so he asked how they knew that the air conditioner failed.

HVAC Guy: It didn't fail. We're just changing the chiller bars and doing some other preventive maintenance.
Mark: But we've got two air conditioners in here, why are they both down?
HVAC Guys: We figured it'd be easier to do them both at the same time. Why, is there a problem with that?

Mark and his team of network administrators spent the next 36 hours or so rebuilding and restoring each server, its backup, and its backup's backup. And as for Phil, the developer who submitted this story, he got the day off.