Best worn at night. A few years back, Brian F. was doing some consulting for a small web startup that was trying to build a platform for struggling artists to sell their music online. After about a year of "nothing of significance" (READ: they ran out of money before signing on any customers), there was little left for Brian to do and his billable hours were "indefinitely" reduced to zero. However, a year after leaving, the CEO called Brian to say that said investors had been found and that he needed some help taking his vision to the next stage.

Granted, while the investors did give the CEO a pile of cash, the company couldn't afford the luxury of funding an in-house, built from scratch system. Instead, they had found an outside e-commerce solution and it was Brian's job to give his professional "opinion" of the software.

Brian thumbed through the documentation which touted massive scalability, parallelism, a full album of screen mockups, and even a mention about quineness of the system...but nothing concrete. Admittedly, the site and layout looked sharp and professional, but with a listing of previous customers suspiciously absent, Brian figured that the only way to make an educated judgment call would be to get his hands dirty in the application's source.

A "Simple" Request

After a month of wrangling with the original developers – two brothers who were petrified that Brian was going to steal their masterpiece and sell it to the highest bidder, or worse, release it as open source – he was granted a glimpse at the source code of the application. It was then Brian who became petrified.

The database, in short, was a train wreck. It had no foreign or primary keys, was only sporadically normalized, and in a lukewarm attempt at performance enhancement, the geniuses had added an index on every single column in every single table. Brian relayed his findings and his emphatic you would have to be crazy to buy this steaming pile opinion of the software, but it was for nothing. The CEO had, in fact, already purchased the software and hired a fresh-out-of-college whiz kid who would be responsible for working out the "kinks" in the application.

Was Brian's ego bruised at this news? Not in the least. After all, Brian was basically there for a one-shot consultation. He was left just happy that the check they gave him was going to clear the bank.

C'mon Back!

Fast forward six months. As the development team (the now burnt-out whiz kid) was largely busy with maintenance, there was little time for much development. The original application had a forum which hadn’t been touched by that point. Since a few customers had requested a forums be added, the CEO asked Brian to get the forum "component" working for them. Since it was already coded, Brian figured it’d be a cinch and agreed.

It took about five minutes of looking at forums code to realize what a horrible mistake Brian had made. The forum software was very different to the rest of the code base. While the structure looked pretty good in a few places, the code certainly was not.

Every variable, every function, and every identifier in the code was named a single letter: a, b, c, d, e, etc. Imagine the $a-$b-$c system, only much worse. Everything – even the PHP filenames, the includes, and the folders those files were in – was named in this manner, and it was utterly impossible to decipher.

Brian's first thought was that it had been run through some sort of obfuscation process. Fortunately, they were still under a support contract with the vendor, so Brian got in touch with their developers and asked for the original, unobfuscated source files. Unfortunately, the developers responded, "what do you mean, unobfuscated files?"

Forum Deja Vu

Hoping to make his life a little bit simpler, Brian started about the tedious task of re-mapping the files and variables to realistic and meaningful names. This wasn't so easy as it involved logging in as the administrator account, doing something, noting the URL and then documenting its purpose. The fact that there were a few miscellaneous, yet simple to resolve errors along the way didn't help much either.

It was in the midst of this tedium that Brian found a little breadcrumb that, though shocking in content and the fact that it was the only comment, wasn't a huge surprise:

/*  Raptor BB - The below SQL to address vulnerability 
       detailed in bug# 05000112 */

Raptor BB (as I'll call it) was a fairly popular open source forum application that, upon further investigation, was ripped off in its entirety: only the file, function, and identifier names had been changed. Brian challenged the famous brothers and they nonchalantly responded "yes, forum's source code was in fact "borrowed" and we’d be happy to send a copy of the map to the original file names and variables."

As Brian learned through the ensuing heated email exchange, the brothers started as out assembly programmers and had picked up a lot of "tricks" along the way that made them better coders. They were "experts at optimizing code" and Brian, with only four years of experience under his belt, couldn't possibly understand. Brian's ideas of "well indented and commented code" belonged in a "theoretical course on the computer science" and had "no application in the real world". But in time, they explained, Brian would come to learn that their way was the right way.

After reporting back to the CEO, Brian explained that they needed to scrap the bundled forum, and it would be quicker to just integrate an open source package. Amazingly, the CEO conceded and, after a few weeks happily coding away, the new forum up and running.

Though Brian had left the project shortly after that, he still kept in touch with the company. While they still hadn't figured out a way to turn a profit, the CEO was able to attract enough risk-hungry investors to keep things a float. As for the brothers, Brian hadn't heard too much, but he figured they were still optimizing away.