K&R has magical properties.To the outside observer, Christopher M's work environment might appear to be a potential breeding ground for WTFs. They supported an "enterprise-level" product and, when a developer noticed a bug, the development manager expected him to just go in and fix it. No change controls, no QA oversight — those were far too time consuming and added little value. Almost anywhere else, this set up would result in chaos, but Chris and his four fellow coders were experts, and they were able to navigate the lack of process.

One day, the development manager decided that, to better handle the bug fixes for their applications and be able to support their growing user base, they needed a new developer. And he knew the perfect candidate. On paper, Winston looked as though he would be an ideal match, and he interviewed even better. Not only did he passed the developer test with flying colors, but when asked about his free time and hobbies, Winston responded with a stern and serious face: "I seek out and destroy poorly written code." His knowledge, attitude, and tendency towards geekery put him over the top, so he was asked to start the following Monday.

Getting Confrontational about Variables

When Monday finally arrived, Christopher showed Winston around the office and gave him his first pre-assignment. It was pretty basic: head on into source control, copy the application source to disk, compile, and give it a look through to get familiar.

About twenty minutes later, Winston showed up at Christopher's desk with a grumpy face.

"I opened up set_constants.c and I have some issues with how it's written", he began.

Christopher was very familiar with set_constants.c - some time ago, one of the other developers decided to store data constants that would be customized for each client inside of a C file (things like license key, etc) instead of a config file. A regret, but it worked.

Christopher sighed, "Yeah, we kind of dropped the ball with that one, we have plans though to fix it."

"I certainly hope so!", replied Winston with arms flailing, "There's some serious sprintf abuse going on in there - copying twenty characters into a variable with a length of twenty-five? I'm REALLY surprised you haven't gotten any angry phone calls over this one."

You've got to be kidding me!, thought Christopher before carefully replying "No, not yet, but we'll be sure to tap you for writing the fix! Good work! For now though, we have some bigger fish to fry with Version 3 of the app coming up and—"

Before letting him finish, Winston scowled and storming off, grumbling.

Two Fisted Fixin'

Three months after being hired, Winston had completed a few assignments and proved himself to be technically very competent. He had a few gripes here and there, but overall, they were just chalked up to the new guy getting used to a new environment.

At this point, the company's flagship application — a UNIX based hard-core data processing application — was due for a new major release. This meant that Christopher would be travelling to client sites with some of the sales guys to talk implementation and answer questions. He was scheduled to be out for two weeks, but felt that Winston would be able to crunch through his assignments with the help of the other developers.

Skip ahead two weeks and Christopher returned from his road show with great news: several of their largest clients were growing even larger, and one in particular wanted their latest and greatest version ASAP. He knew that there was still some polishing to be done before he left, but figured that the fixes would be addressed during his absence. So, he went about burning a copy of the installation CD to send off to the customer. But as he put the blank CD into his drive, he noticed something strange: there were two directories labelled DISC_ONE and DISC_TWO.

Puzzled as the application easily fit on one CD (including documentation), Christopher checked CVS to see what kinds of changes had been made recently. It turned out that within the past month, Winston had touched every source file in source control with the harmless-looking comment "General Code Cleanup".

Apparently, during Christopher's absence, Winston had been assigned a task of hunting down a tricky memory leak. This was a tricky task, but doable with the right amount of testing and debugging, which was straight up Winston's alley. However, left to his own devices, Winston decided to take his task to the next level and comb through the application's thousands of C source code files and change every single variable to be initiated on the stack. What did this mean?

In every library and every program, where variables were originally declared and assigned as:

int main (int argc, char **argv) 
{ 
  int x;
  char data_string[15];
  ...
  x = 2;
  strcpy(data_string,"data data data");
  ...
}

Was changed to:

int main (int argc, char **argv) 
{
  int x = 2;
  char data_string[15] = "data data data";
  ...
}

What to do with a Reckless Coder...

Christopher was speechless, as was the development manager. Sure, developers were expected to fix bugs as they found them, but this... this all-encompassing carnival of carnage was beyond imagining. Clearly, this meant that the process was broken and that maybe, just maybe it was time to bring in some change controls and QA oversight?

Nah! The development manager realized the real problem was Winston and that he needed to be fired. Of course, instead of that he was "promoted" to "Data Administration Analyst". The fancy title meant that, not only would he be the guy who the support staff rang whenever there'd be a data problem, but that he could only analyze the code. Not actually change it.

At least it solved one problem.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!