"If you want My Space or American-On Line web pages," Dmitri confidently told the Wall Street executive before taking another long drag on his cigarette, “then hire New York programmer to build.” He exhaled, filling the air in the posh Moscow bar with even more smoke, then leaned in to say, “but if you need real, smart, mathematically strong system, then you hire Russian. Who you think build Google? Russian!”

Dmitri’s words were mostly redundant. Even before flying to Moscow, the executive was convinced that The Russian Plan was the only way to go. As Dmitry put it, the perfect storm of a bankrupt Russian trading house, mixed with contract disputes, Kremlin intervention, and an untimely death or two, allowed him to acquire the source code and intellectual property rights to an advanced, realtime foreign exchange trading system.

The Russian-built forex system, Dmitry explained, was light years ahead of other Russian systems, let alone the American ones. “It is closest thing to crystal ball,” he said, “and it only need few tweaks for working. But, I have first-hand experiences with, as I was chief architect.”

The executive was sold. Not only did he buy the forex system, but he also hired Dmitri to help get the system online and integrated into their backend systems.

Let the Tweaking Begin

When the executive announced the acquisition, the IT department was not too thrilled. They certainly weren’t about to let some programmer living halfway across the world have unfettered access to their corporate knowledge and intranet. So they hired Brett Alistair.

As the Offshore Coordinator, Brett’s job was to “keep an eye” on Dmitri and to help him integrate with the existing Oracle databases and other backends. Although he was new to realtime trading, Brett had a feeling that the code was more than “a few tweaks” away from completion.

The server component frequently crashed and, due to its efficient-yet-fragile “in memory” approach to storage, all customer transactions since last save would be lost. In addition to the numerous defects in the code, it was apparent that Dmitri was not really the architect of it all, nor was he the hot-shot C++ programmer that he claimed to be.

Dmitri was also not very happy with source control systems. He claimed that CVS was notorious for “corrupting” commits, and he preferred the safety of the file system. Fortunately, Brett was able to convince him that the problem was his own: Dmitri would sometimes switch between Windows and Unix, but when he checked-in Windows-edited code from Unix, CVS didn’t prune the extra carriage return, so the files grew with an extra blank line between every legitimate line. This made debugging the (many) crashes and assertions impossible, as the compiler would report one line but the editor would jump to another. Eventually, Dmitri learned to use CVS “for real” and development continued.

Over the next several months, Brett and Dmitri hammered away. Injecting rigor into the code was easy: simply rewrite every other line with proper coding and error checking. But no matter how hard they worked, it was far too much work for two men. Even if one of them was a slightly crazed and fanatical Russian.

The Russian Team

Per Dmitri’s advice, a team of six developers were set up in Moscow. Labor over there was cheap, good quality, and, most importantly, totally trustworthy. Those coders would be responsible for the customer and manager user interfaces.

Upon first glance, the Brett was impressed with the look of the UI screens. The code, on the other hand, left little to be desired. Instead of using inheritance and refactoring common code, the Russians were simply taking the last “good” codefile and then copying it and improving it in a new codefile. This meant that some defects would have to be reported and fixed several times across different modules.

Management cared little for code quality, leaving Brett uninspired to review code. But by chance, buried within a several-thousand line method, he noticed something a little off. There was some code in there that looked for certain “magic numbers” in transactions and then dealt with them specially.

Close inspection of the code revealed that the crafty Muscovites were writing an auto-trading application in order to exploit the system. Had Brett not found the code, the system would have back-dated “special” transactions so that one could execute a buy order after the price skyrocketed at the original price.

After Brett reported the exploit, the Moscow team was quickly disbanded. Dmitry, who traveled back-and-forth between Moscow regularly, was advised to stay there next time.

Bringing it Back Home

It took almost another full year and a rather-expensive team of New York contract programmers, but the application was finally live. It wasn’t Earth-shattering, nor did it give the company a competitive advantage.

In the two years since going live, a couple off-the-shelf trading systems introduced some key features that their system was lacking. In order to keep up with the competition, the company decided to develop a second version of their proprietary trading system in-house.

Well, kind of. There’s a second team working out of a satellite office. Labor over there is cheap, good quality, and, most importantly, totally trustworthy. It’s not in Moscow, though.

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