Originally posted to The Sidebar by "ObiWayneKenobi"...

Last year, I took a position as the “Director of IT Services” for a tiny, six-person e-commerce company. The fact that I wouldn’t be managing anyone should have been a red flag, but I hoped that I could get approval down the road to build a real IT department.

It didn’t take me too long to figure out what a hellhole this company was. The owners were a husband-wife team, though The Wife was the “legal owner” so the company would be woman-owned (and therefore eligible for minority business status). And they were cheap. Really cheap.

All the computers were refurbished, 5-year old machines that they got from a liquidation auction or something.

  • The computers ran Office 2000 off of what appeared to be pirated discs, although the owners assured me that they purchased them legit at the auction.
  • The network consisted of an almost ten-year old domain controller running Windows 2000 that nobody used and various five-port Linksys hubs strewn about the office to connect computers.
  • They were too cheap to pay for hot water. That’s right, we had no hot water in the office. I asked about this one day and, without skipping a beat, my boss (The Husband) said “Hot water costs MONEY!”

The system they used to run their business was a cesspit of spaghetti VBScript/Classic ASP code that was based on an open-source package called Comersus. They spent a hefty sum of $200 for it.

I can only guess that their rationale was they could buy a bare-bones package and then pay a programmer to make it better. Unfortunately for them, the person they hired, my predecessor, seemed to know as much VBScript as it took to read a “Teach Yourself VBScript In 24 Hours” book. Which happened to be about as much VBSscript that the author of Comersus knew, as the code was very similar: a textbook example of cargo-cult programming at its best (or worst, in this case).

The code was not commented at all, used cryptic variable names (seemingly all without vowels) and had zero indentation, especially when it came to nested statements. Oh, and there was over 15,000 files.

To complicate matters even more, the company had “licensed their technology” to another company in the same line of business. This partnership consisted of my company doing all the processing work, and the other company... well, I never did figure out what they actually did.

My predecessor tackled this partnership by creating a copy of our database and site, and renaming some twenty-four configuration values in “tbl_settings” to reflect this other company. This, of course, meant that there were now some 30,000 files floating about, and that any change I made to fix one site had to be repeated with the other site.

Perhaps the worst part of the site(s) is that it was originally designed to be bilingual (English and Spanish). To accomplish this, there is a “languages.asp” file that contained... you guessed it, a dictionary object mapping certain sections to the equivalent words in English/Spanish. This lead to code snippets such as the following: 

Response.Write dictLanguage("prod_view_45") & ":" & dictLanguage("currsymbl") & prce

Obviously, “prod_view_45” is the string “Your price.” Of course, the site is actually English-only, but my predecessor never bothered to change this, making even a mundane fix a matter of hunting through hundreds of random strings.

On the business end, both companies sold products to the federal government by “utilizing” their minority status: by federal law, a certain percentage of business must be given to minority-owned businesses. It should come as no surprise, however, that there was absolutely no business process and certainly no workflow for how to get things done.

The entire operation was basically a fly-by-the-seat-of-your-pants sort of thing, and my daily work ended up consisting 90% of running reports for The Husband so that he could make up different pricing. I brought up the issue of trying to establish a workflow to avoid just dropping things in my lap, but he said that their simply wasn’t time for that due to the restrictions. On top of that, even a simple bug took days to fix due to the convoluted mess that was the code, and most of my programming tasks were aborted because it “took too long to fix.” I tried again to explain the concept of “technical debt” and how bad the code was, but my concerns were dismissed.

The last straw came in preparation for a deal with the Air Force. In a fit of brilliance, The Husband decided that we would offer exactly the same line item they requested. If they wanted “12 notebooks”, we would create a “new” item called “Notebooks, Package of 12” instead of selling them twelve individual notebooks. As you might imagine, this involved all sorts of special pricing, which then had to go through several different channels because it was sold to the government.

On the first attempt of getting this set up, The Husband mistakenly told me to change the wrong pricing file and then completely exploded when I followed his instruction and changed the wrong pricing file. He screamed profanities at me, and said how everyone in the office (except for himself and The Wife) didn’t know anything and was a complete screw-up (he used a somewhat more vulgar term).

In the end, fearing another blowup, not wanting to deal with a company that had no idea what they were doing, and had no desire to change, I gave my two-weeks notice and resigned. While I didn’t have another job lined when I quit, I did learn a valuable lesson. Next time, make sure your prospective employer pays for hot water.

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