Eins, Zwei, Zuffa!

Dave had been at Initech for a few years, and things were looking pretty good. Everyone was working towards a big project launch, and every team was on target, on schedule, and on budget. The management, however, was not confident, and decided to "increase quality". Their solution was to bring in two experienced, highly-paid consultants from the land of engineering excellence: Germany.

The two consultants were Bob Schli1/4dell and Bob Gepicktriger. They became known as Bob Eins and Bob Zwei. They assessed the situation, then rolled up their sleeves and started hacking on all of the projects and code bases with their special skills.

And how special those skills were.

Bob Eins had two favorite things: C++ templates and threads. Anything that used both of these was good, and everything that did not was garbage and had to be rewritten to use threading and templates. He would take whatever library the company was using, reimplement about half of it with layer upon layer of templated classes, and inform the team that, "You will use this from now on!" Then he would start working on a new library and abandon the previous one, meaning that all of his code was unmaintained.

Bob Zwei was a different kind of beast. At his previous job, he had worked on some project codenamed "Volcano", and that was all he ever wanted to talk about. Ask him any question from, "Have you seen this compiler error before?" to "Hey, we're all going out to lunch today, wanna come?", and he'd respond with, "You know, back when I was working on Project Volcano"" followed by twenty minutes of chatter about design problems completely irrelevant to the initial topic of discussion.

Dave managed to keep under the radar of the Bobs for awhile, but eventually they found him. They gave him a new core library to use. He sighed and went back to work. How bad could it be?

It was much, much worse than he could possibly imagine. The first thing he learned was that these two Germans were very organized. Majorly, pedantically, obsessive-compulsively organized. Even the most uptight librarian would tell them to loosen up. Due to this, the Bobs demanded that everyone follow strict namespacing standards to keep code organized. However, each of the Bobs had their own radically different scheme.

For example, a network socket class implemented by Bob Eins- because socket.h was Not Invented Here, and thus not good enough- was namespaced as base::universe::posix::network::socket::Constants::IPV4. It was unclear what existed outside of the base::universe namespace. Meanwhile, Bob Swei organized all his classes along the convention com::initech::divisionname::projectname::objectname, and refused to accept the reality that some projects spanned divisions, and thus couldn't be slotted into that hierarchy.

This was all somewhat manageable until Bob Eins dropped the biggest bomb. His NIH-itis flared up again, so he wrote his very own signal/slot mechanism. All existing code needed to be converted away from Qt's perfectly usable mechanism as soon as possible. The unique feature of Bob's version was that everything was a thread. Every service? Thread. Every operation? Thread. Every object? Thread. Every method call? Thread. Everything. This would, it was gloriously announced, get rid of the bottleneck of having a single event loop running on the main thread.

Bob Eins answered every objection raised by the other developers with a variation of, "That is not an issue!" No reasoning was ever given. Future maintenance costs were "Not an issue!" Throwing away a year's worth of working code was "Not an issue!" The massive amount of threading bugs, resource contention, and overhead were "Not an issue!"

Bob Zwei answered every objection raised by the other developers with a variation of, "You know, back when I was working on Project Volcano""

All work ground to a halt. Because of the liberal use of templates, the project's compile speed would have brought ridicule from a severely asthmatic snail. A "Hello World" for their framework took two minutes to compile. The full suite could take hours. Most developer time not wasted waiting for the compiler was spent adding mutexes everywhere, since you could no longer rely on any variable not magically changing out from under you. And the rest of their time was spent debugging race conditions, deadlocks, and resource leaks.

Eventually, the Bobs stepped in with a new solution: every object in every thread would run its own personal event loop.

Nothing was getting done, and management started getting anxious. One morning, Dave's cube-mate was grabbed from his multiple week stint of fixing threading bugs into a meeting and shouted at for what seemed like forever. Dave could hear the muffled shouts. "Because your component isn't finished, you are personally jeopardizing the future of the entire company!"

After a particularly fruitless bug hunt, Dave had no idea what could be causing his race conditions, so he figured he'd ask Bob Eins. He described his problem. Herr Eins glanced at his code for a microsecond and said, "There is nothing wrong in the platform. You are just using it incorrectly."

"Is there any documentation on how to do this correctly?"

"There is no need for documentation. Just read the source code," Bob Eins replied. He waved a hand and wandered off to do more template metaprogramming.

Dave went to Bob Zwei next. "You know," he began, "back when I was working on Project Volcano""

Dave didn't want to look at the library sources, for they used every possible C++ misfeature and were as impenetrable as Mirkwood. After battling the digital equivalents of spiders and elves in a dense thicket of intertwined templates, he finally found what he was looking for: a helper class for the signal system. It was unusual, in that it had a comment, possibly the only one in the entirety of the Bobs' code. It looked like this:

 // This class is not thread safe

Dave's jaw dropped so low that you could have flown a 747 through his mouth. How could a core component that was used everywhere in this multithreaded messaging system be thread unsafe? He filed a bug asking if this issue could be fixed.

A few hours later, Dave's boss tapped him on the shoulder. In a strange tone, he said, "I've been told that you filed a bug on Bob's new signaling system."

"That's right""

"I want you to know that sort of behavior is totally unprofessional."

Instead of shouting, "What?" at the top of his voice, all Dave could do was sit there, stunned.

"You really shouldn't be spending your time finding bugs."

This sentence was even more incomprehensible than the previous one, so Dave just kept staring.

"In this company, we need to have an agile, startup-like mentality, with a focus on results and collaboration, rather than over-polishing minor niggles in our already established core infrastructure."

Dave wondered if he had been teleported to Bizarro World, because not a single word he heard made sense.

"This is the last straw in a long line of disappointments, and we feel that there is no future for you in this company. Please clean your desk and leave the premises immediately." Five minutes later, Dave was standing alone in the parking lot.

Then it struck him. The unemployed don't have to deal with threading issues, namespaces, or supertaxonomies. Dave smiled, for the first time in months, and decided to celebrate by going on vacation. He started thinking of good places to unwind, but with two hard requirements.

One: it must not be in Germany. Two: it must not have any volcanoes.

[Advertisement] Release!is a light card game about software and the people who make it. Play with 2-5 people, or up to 10 with two copies - only $9.95 shipped!