I wanted to tell you about an experience a friend of my recently had, that you might find amusing, or maybe just stunning.

We’ll call this friend of mine “Peter”. Peter was an out-of-work computer programmer who got a contract job at a huge software company. Let’s call that company “Initech”.

Peter had never worked at a company this big before. The company had just downsized its space and so the office where his cubicle was located was the home for 20 or 30 other cubicles, all about three feet wide. Wait… Did I really mean to say three feet wide? Yeah, I did. And that wasn’t all the programmers in the company. That was just some of them.

I won’t bore you with the details of Peter’s day-to-day routine. That’s not really the point. But the lessons he learned from the experience bear repeating. I’ll put them in list form, in no particular order, just the way they were relayed to me (although they were relayed to me with a lot more gesticulation and emotion than I’m going to express).

• Make sure your internally built software suite involves thousands of files of virtually undocumented software. Make sure that hundreds of those files have to be fetched and interpreted before a single byte is displayed in the browser.
• Make sure that the software follows the latest industry “best practices”. Apparently this means that, no matter how bad it is, guys who read Datamation magazine and “academics” will love it regardless.
• Make sure that it’s virtually impossible to fully understand the software framework without assistance, and then make sure that everyone is so busy they can’t take time to mentor new people through it.
• Make sure that there are at least four (yes, four) levels of testing for any changes which are made to the software. Did I mention it was four levels? Yeah? Okay.
• Make sure that in order to even begin to think about modifications to the software, there are at least three different types of documents required.
• Make sure that, in order to move the software from one level of testing to the next requires masses of documentation and byzantine procedures, performed with various software programs which don’t interoperate well with each other.
• Make sure that the mandatory software reviews which have to take place at each level of testing are performed by other programmers who volunteer to do them, and then ensure that they’re all too busy to volunteer.
• Make sure that when you’re explaining all this to the typical new programmer, you do it in a form of English called “speedspeak”, guaranteed to be faster than a human can comprehend, much less make notes from. Make sure that everyone else is too busy to explain all this as well.
• M.S.T.U.P.O.I.A. (Make Sure To Use Plenty Of Incomprehensible Acronyms). If you run out, borrow some from Datamation or the government.
• Make sure when you call the database controller, you call in the drivers for every single type and kind of DBMS you might use, even though you’ll only be using one for a given web page. For example, if you’re only going to be using MySQL for a given page, make sure you call the Oracle, DB2, MSSQL and Sybase drivers as well. Just in case.
• Make sure when you talk to the database, you start a timer, and after you’re done, stop the timer. Also log and record the details of every connection to the database and every query. Even though this is normally completely unnecessary, it ensures adequate latency.
• Make sure that everyone is so inured to these procedures and this software that, if questioned about it, they’re guaranteed to come up with any number of non-sequitur reasons why it “has to be this way”.
• Spread rumors that, at some point, there will be a Version 2 of this huge software framework, which will also be built based on “best practices” (and thus, ten times as horrendous).
• Demand that all documentation gets the new TPS report cover sheet attached. Send out a memo about this and ensure that at least three people complain to anyone who violates the policy. (I’m joking about this one. Peter never mentioned TPS reports when we were talking. Of course by the end of the evening, I was a little fuzzy on details.)

You may think Peter was exaggerating about this stuff. I assure you, he wasn’t. Peter’s not the kind of guy to embellish things. And Peter wasn’t the only new programmer hired on at the time. There were others. And when he consulted them about all this (just to ensure he wasn’t going insane or something) they reacted with the same level of incredulity he had to all this.

Now, if you’ve ever seen the movie Office Space, you immediately know why I’m calling my friend “Peter” and why I’m calling this company “Initech”. But what’s really funny is that, toward the end of the month Peter worked for this place, he decided to order the “Office Space” kit from ThinkGeek. It includes various items from the movie, including a coffee mug with the name “Initech” on it, and a genuine TPS Cover Sheet. His idea was to bring the mug in and drink his water from it throughout the day, and tack the TPS Cover Sheet up in his cubicle, just to see if anyone noticed and got the joke.

The kit came in the mail the day they laid him off, so he never got the chance to see if anyone would get the joke. Their explanation for the lay off was that he obviously had the programming skills for the job, but didn’t fit in with the “corporate culture” at the company. Just as well, because he hated the job.

(Incidentally, neither ThinkGeek nor Office Space sponsored this post, nor have anything to do with it. Also, I’m not attempting to impugn the reputation of Datamation magazine. I haven’t seen a copy in years. But years ago, it was the “go to” publication for people in the computer industry who wanted to think of themselves as well-educated. As for “academics”, well, I don’t think much of them.)