When programmers disagree, generally one of two things happens. One, they talk it over like mature adults and agree on a solution that works for everybody. Two, they have a swearing match that ends on an angry compromise, then the programmers go off and do their own thing anyway and blame the whole mess on a "miscommunication."

Guess which path was taken by Skip S.'s predecessors.

Skip was close to graduating with an advanced degree in Computer Science, when he picked up a job as a C developer. The company had stumbled onto success against all odds when writing an application for a claims adjuster. The sweet taste of accidental success roused their ambition, so they decided to scale up and port it to the then-cutting-edge Windows platform.

The Right Way(s)

The existing software had been assembled by a team of *NIX developers who knew a little X. They all sat in close proximity to one another, which initially fostered productivity, but eventually fostered hatred. Internal conflicts over minor issues divided the team to the point that communication effectively broke down, aside from quietly, angrily muttering to onesself.

Each programmer knew The Right Way, and that each other programmer on the team was a drooling moron that did nothing but pollute the code. One would angrily check a code file out, make a change that wouldn't change the code aside from supporting the developer's ego, and check it back in. This eventually gave way to programmers making their own versions of a class so that they wouldn't have to use code that they hadn't written personally.

After a year or so of arguing, duplicating functionality, and arguing some more, the team started disappearing. And it had worn down to the point that there was just one guy left. This when Skip joined the team, and got to know "Lars." Lars filled Skip in on all the background. "And good riddance to the team! I was the only one that knew how to code, that's why I rewrote so many of their stupid modules."

Although things were almost entirely in Lars's control, he had chosen to leave as well. He'd be around long enough to train Skip and then hand over the reins. The training process was, in a word, useless. Lars spent hours explaining their source control system (which Skip was already familiar with), explaining how to use vi (Skip already knew), how MAKE commands work (Skip already knew how to type "make"). After the training, Lars left for good.

The Backup Plan

The only part of Skip's training that was remotely useful was when Lars showed him how to make a backup. "You take a tape from here," he said, pointing to a pile of tapes, "then you do this," he said, typing on the keyboard, "then you put the tape here," he said, pointing to a neatly arranged stack of tapes. When Skip asked how the tapes were arranged and if they had any labels, Lars said they didn't need them, since the stack was always kept in order.

When a client noticed several newer features disappear from the application, it didn't take long for Skip to find out that someone had restored from the wrong tape. Returning to the room, the once well-maintained stack was now a disorganized pile. Skip's boss had tossed all the tapes into a box prior to a big client's visit, and just dumped the tapes back on the table afterwards.

This is when Skip learned a valuable lesson — often, the best solution to a problem is adjusting the client's expectations.

Skip had inherited two things with Lars's departure: around 100,000 lines of passive-aggressive C code, and a number of customers that he could count on one hand, even if said hand only had three fingers.

The Message Queue

One thing the previous team had agreed on, apparently, was that the built in wprintf() and wsprintf() functions were no good. Specifically, while these functions were designed to output characters to a buffer, the team decided that they should instead pop up a dialog box and have some additional functionality. And they'd each agreed to create their own functions named wprintf() and wsprintf() — not to be confused with wprintf() and wsprintf(). Each of these functions, in their own unique way, would instantiate a dialog box and, optionally, any number of buttons and input boxes.

With this implementation, though, they had to figure out a way to show multiple dialogs at once. At first, opening a dialog while another was open would just replace the contents of the existing dialog. Somehow, the team agreed on a solution — they'd create a stack, push data on to it from the previous dialog, then grab it back when the user returned to the dialog. Simple!

But what about going back and forth between dialogs? Make the dialogs modals! That way, the user has to deal with the dialog in front of them before the next is displayed. Simple!

One problem, though; computers are slow! The team agreed that a linked list would be too slow, so they'd make an array of pointers of a reasonable size for the dialog data. Six ought to be enough for anybody. If more than six dialogs appeared, something was probably wrong.

Out in the real world, though, take this hypothetical situation. Mom, dad, their four kids, and grandpa need coverage. You enter the names and information for everyone, then get to grandpa. You keep clicking OK, OK, OK, OK, OK, etc. until finally the system hangs. Grandpa filicided dad right off the stack. And dad's the policy holder. And now things get confusing.

Somehow, Skip managed to keep the code going for a few years.

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