The worst program I ever worked on
Most contract jobs fade pretty quickly in memory after the work is done, but some you remember for the rest of your life. This is one of the latter variety.
This happened long ago, at a (fair sized) company that shall remain nameless. The software was a chunk of code that had been maintained by a single guy that had been fired recently and was a core component of a commercial system.
So far nothing unusual, companies tend to find out that they have a piece of critical knowledge in one head all the time, usually if something happens to or with such a person there is a mild panic, some days of frantic reading and then life continues.
Not so in this case.
Some bug had popped up in this program and the guy assigned to fix it had come back alternatively laughing and crying babbling nonsense about \'pizzas calling hamburgers and passing booze\'.
The programmer that had written this code had his own sense of humor and his own ideas about the term \'job security\'. We\'ve all heard the tall stories about the accounting package that wipes all records if there is no payment to some off-shore bankaccount 48 hours after terminating some tech guy, but such tricks are relatively easy to deal with - assuming that most of those stories are true, which I have a hard time believing, and I\'ve never seen any of those in real life.
The software this guy left behind did not have any logic bombs or other nasty tricks in it, it compiled just fine, and besides that one bug it seemed to work fine as well. Imagine this though: every function and variable name in the program was named after food. Pizza\'s, tomatoes, pickles, various kinds of cheese, fruits, vegetables, drinks and so on, for page after endless page. The only place where the names made any immediate sense was \'main\' and any C stdlib calls.
So I got handed the thankless job of working very hard to get the program back to a state where it could be maintained.
It was a really nifty form of encryption, and only with a key in hand would the salad of code make any sense. Little by little I converted the program back by naming the functions and the variables with more sensible names, and as the work progressed it got easier and easier.
Working backwards from a known function and source code is a lot easier than reverse assembly of unknown code (because then you first have to separate code/data and you have to figure out what the high level representation was, here I had the high level representation in plaintext in front of me), so it wasn\'t that the job was impossible or even particularly hard, it was just tedious. Once a function or variable had been identified to have some probable meaning a new name was made and a search-and-replace took care of the actual renaming.
Another problem was that it was bad code, in fact, the various spaghetti twists in the code did more to obfuscate the meaning of it than the lack of meaningful symbols, so once I had all the functions and variables renamed back to something that made sense I re-wrote a good bit of the code to make it easier to understand and work more efficient.
I never did find out if he had a non-obfuscated version of the code that he ran through a \'blender\' script that obfuscated the original code by stripping out any and all comments and replacing all symbols by nonsensical ones. I find it hard to get in to the mind of someone that does something like that to begin with but I find it even harder to imagine that he wrote code like that directly, that would have actually been an amazing feat.
Of course, if in your head you think that they can\'t fire you because your program makes no sense (or that they might hire you back) then you\'re delusional so whatever goal this guy had with his trick it failed in a terrible way (I can\'t imagine him giving his former employer as a reference either) but it made for an amusing couple of weeks, and a very happy customer.