Woof.Steve had been passing by SecuriTek's in-your-face full-sized billboard job ad every day for nearly a month. They utilized the "geek appeal" of twisted logic puzzles and obtuse syntax to lure in candidates with perks in their "laid back yet professional" environment. However, along with their promises of catered lunch wishes and every-day-is-casual-day dreams, the advertisements made one thing perfectly clear - only the best and brightest C/C++ developers on the planet should apply. Thinking Hey! I'm a Top-Tier kind of guy and What the heck...I don't have anything to lose Steve decoded an obfuscated HR email address (ROT13? C'mon...) and sent off his resume.

To his delight, their HR called soon after to schedule an interview. After a short "Hi. How are you? Nice weather!" with the HR rep Steve was put straight into the next stage of his interview - a programming test. It was an insidious test involving string processing, trees, and data structures that took over an hour to complete. But within minutes of finishing the test, Steve learned that, out of hundreds who took it, he was one of the few out who managed to pass it. Afterwards, Steve was offered and accepted the job.

Welcome Aboard!

Steve arrived to the "standard" fanfare of any new SecuriTek employee - an edible bouquet waiting for him at his desk, a top o' the line laptop, 24" monitor, executive-style chair...and orders to hang tight until they had some work to send his way. So, like any corporate "newb" with his hands on the keys to the castle while awaiting his first real assignment, Steve hit the books, or rather the corporate Sharepoint portal. After first learning the inner workings of the company's flagship application (developed in C++) he brushed up on improving his fundamentals, optimizing memory, and all the other "best practices" that earns A+++ developers points in the corporate world.

After a few days of working — or more accurately, waiting for work — Steve felt pretty stoked to be able to handle any oddball enhancement or bug related to a dangling pointer that would come his way. However, when the first assignment arrived, Steve found himself in a difficult place. It wasn't some esoteric C++ bug, but instead a test script to get him familiar with the company's flagship virus detection app. It wasn't a "script" intended for execution by some interpreter, but instead one that was printed out and executed by a human. Worse still, the document resembled a cryptic sphinx riddle than a bug description.

...
7. Perform all of the necessary pre-initialization steps as described by script 118T-B.
8. Open Microsoft Excel as prescribed in script 0G17.
9. After clicking on "Virus", take a screen capture (see script 0G22).
10. From the printout, enter each item into Microsoft Excel.
...
18. After clicking on "View Report", click on "Print Report".
19. From the printout, enter each "Virus" item into Microsoft Excel.
20. If the Excel spreadsheets do not contain identical data, the test has failed.
...
 

Steve began repeating out loud if only to confirm that the language centers of his brain had not been fried. It turned out that the test script could be simplified as "Verify that items which appear after you click on 'Virus' will be listed on the 'errors report'." That could have taken two minutes, and thanks to the genius developer who had already fixed that particular bug, Steve spent more than two hours fruitlessly testing a working feature.

As the days of performing test scripts passed by, Steve couldn't help but wonder why are there so many JavaScript and HTML bugs. That and, what the hell does this have to do with C++? As Steve become more acclimated with his coworkers, he began to wonder something else: why are so many "developers" doing test scripts all day? Shouldn't they be fixing bugs instead?

The answer came in the form of the company's in-house developed scripting language that Steve came to call "WTFSL"

Security Through ...Obscurity?

Like many horribly tragic enterprisey solutions, WTFSL was the nepotistic brain child of the company owner's cousin. Besides not being the least bit extensible, WTFSL featured a limited set of functions. Floating point math? Nope. Regular expressions? Sorry. Advanced string handling? Sort of... Handling strings larger than 64K? Wishful thinking. Garbage collection? Only if the developer remembered to deallocate local variables - in fact, this was the source of many crashes and out-of-memory bugs in the product. Things were so bad that nearly all data validation was forced to be handled in the user's web browser because of WTFSL's impossibilities. It was, however, originally written in C++.

Steve considered making an argument in very best interests of "the greater good" (namely the sanity of the company's development staff), like implementing future version using a liberal-licensed scripting language like LUA or at least allow a hook into something a little more well known like PHP or even SNOBOL at this point, but it was a hopeless case.

Besides freely admitting that WTFSL as being the most secure language to develop in (only 10 people, tops, on earth knew how to code in it), the owner's cousin who first dreamt up this sasquatch of a language was on the board of directors. "I'm sorry, I can't just tell him to throw his work to the garbage" was the usual reply if someone suggested that they use something else.

"Don't worry," Steve's coworker said in response to the why are we testing bugs all day question, "it's always like this before the launch of a new version. Once we're out of beta, it's right back to the code."

Coding, as he found out, wasn't going to be C++, but instead WTFSL. "Some day," his coworker added, "you'll work on the language core. But you gotta give it some time. I should be starting on that team next month!"

His coworker also happened to be "one of the best C++ developers the company could find", though he had started at SecuriTek nearly three years earlier. As enticing as it was to maybe code in C++ some day, Steve chose not to stick around. But his former coworker should be joining that team any month now!

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