"Welcome aboard, Colin!" Colin P. gave his boss a firm handshake, excited about his first day on the job. He'd be a member of the team that worked on an application that ran on a managed information appliance. "I'll set you up with Mike, who can show you the ropes."

Colin's boss turned him over to Mike, who started describing the system architecture immediately. "So here's what we've got," he began. "The core is the email processing module. It takes in an email, logs a little information, and stores attachments in the file system. Easy, right?" Mike gave him a little more background, but reasoned that Colin should be able to figure it out.

It sounded so simple that Colin could hardly imagine any reason that they had more than one developer actively supporting the application. That is, until he saw the architecture (to use the term loosely). Try to follow along:

The core of the application was a system which processed items of incoming email, logging some information to a database and storing attachments in the file system. A Perl web-app controlled the behavior of the system and allowed access to the results. Of course, the system had to interact with Microsoft Exchange servers, since that's where most of the clients stored their email. It also had to interact with various third-party products which were Windows-only. So, naturally, as a host operating system for their appliance, they chose Linux. The web application would run natively under Apache, with the rest of the sytem running inside a virtual Windows XP host in VMWare. The two would communicate via HTTP, with the Linux host invoking a mixture of Perl and VB scripts under IIS on the XP guest to communicate with the Windows components.

I tried to represent this with a flow chart, but did an embarrassingly terrible job of it and wasn't going to include it with the article. Then after thinking about it some more I realized that the quality of the flow chart is a good metaphor for the quality of the process. Generally, the squiggly lines represent HTTP requests and my own ineptitude with Visio.

Because the application had to work with Exchange servers, it would stand to reason that they would design the interface using the Exchange SDK. Instead, the system required an instance of Outlook running on the virtual XP machine to move the emails around. Colin discovered this on his third day when he got an call from an upset client that their system was hanging. He had to solve the problem with the following process:

  1. SSH to the customer's Linux host
  2. Open a port to allow VNC or Remote Desktop access
  3. Connect via VNC or Remote Desktop
  4. Click 'OK' on whatever dialog in Outlook was awaiting a response

The Perl-based management web application had four routines in it, which represented over 70,000 lines of code. That count includes comments, but only because there weren't any. Most of it was un-indented and had been copied and pasted from sources unknown.

The lead developer was notoriously cagey, and meticulous about his code. So much so that he wanted to keep his code a secret from everybody. After all, if he checked his code in to source control, that would mean that other developers could *gasp* see it, and perhaps *double gasp* maintain it. So instead of code, he'd check in compiled assemblies.

Colin butted heads with the lead developer near the end of his first week about a scheme he'd developed for passing hierarchical data in Perl, using a jumble of arrays of values prefixed with period-delimted path names. Colin's suggestion that it might be easier to store the hierarchy directly using hashrefs was met with a five-second blank stare, then a suspicious and dismissive "that sounds very clever," before he returned to his explanation.

Before he'd even finished his first two weeks, Colin knew that he had to move on. Since Colin had interviewed with the CTO, he intended to catch up with him to discuss his plans. That morning when Colin came in, he discovered that the CTO had gone on safari, but he hadn't gotten around to telling anyone he'd be gone or where he was going. Instead, Colin sent an email to him, CCing his immediate boss with his intention to leave in two weeks. Trying to be as polite as possible, he explained the circumstances he had worked under, and appologized for needing to quit so soon. Colin tried to keep the tone pleasant and professional to avoid angering the CTO. It didn't work.

In a heated response, without even the slightest hint of the irony of it, the CTO scolded Colin by saying that his level of professionalism was barely suitable for a position at McDonald's, and that he should "just leave right away."

After that, Colin had to fight with HR and the CTO for several months to squeeze a paycheck out of the company for his few weeks of service. When they finally agreed to pay, the CTO gave Colin two options. 1) Pick up the check in person, get yelled at by the CTO. 2) Receive check by regular, un-trackable mail (as long as Colin signed a statement releasing the company from any responsibility if the check mysteriously didn't turn up at his house).

Colin chose the former.

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