"I started work in my new job as Technical Manager full of enthusiasm, only to be thwarted by a flabbergasting array of absurd working practices imposed by the despotic dinosaur of a Development Manager I have to report to," Amanda L. writes.

"What makes this more fascinating is that:

  1. "this list is not a collection of experiences or anecdotes picked up from different sources.
  2. "this list is not an embellishment of any existing practices at this company.
  3. "this list is a genuine and accurate description of the real working practices currently being practiced at this company — nothing here is invented, it is all true.

IT Infrastructure

  1. "Viruses can be picked up via networks.
    Hackers hack in to computers via networks.
    Viruses are bad.
    Hackers are bad.

    "QED: networks are bad. It's obvious when you really think about it! Therefore, there is no company network.
  2. "The company diary is on the Diary PC. We all have to log on to the PC to look at the diary. This means having to walk to another office and hope no one else is using the aforementioned Diary PC. Remember: there is no network.
  3. "There's also an Email PC! This is another walk to a different office: all email addresses are in the same Outlook session. No one is allowed to have email access on their own PC (someone might download something from a hacker). If you are waiting for an important email from a client you have to lurk around the PC or keep having to walk back and forth between your office and the Email PC Office. The DM's recommended practice is to ask the person sending the email to call us when they've sent it.
  4. "There is no file server, as that would encourage network usage. Files are transferred using USB drives (each member of staff has a USB stick or drive).
  5. "Backups: not a chance! When I started I asked about the backup procedures. I was told that all the software was stored on the 'software notebook.' Yes, a notebook. After that announcement the conversation went like this:

    Me: "Oh. How often is the notebook backed up?"
    DM: "Erm..." [ He glances at a developer. ]
    Dev: "Ermmmm..." [ Developer glances back at DM like a rabbit caught in headlights. ]
    DM: "Ahhhh... er..."
    Dev: "I think it was backed up about 3 months ago."
    Me: "Riiiight... ok... and how is it backed up?"
    Dev: "I think you have to run a script."
    Me: "Any idea which one?"
    Dev: "I think it's on the desktop."
    Me: "Ok, thanks." [ At that point I decided it needed some independent investigation. ]

Configuration Management

  1. "Source code control: heh, yeah, right... they have this 'source code notebook' on which all the source code is held (no servers — networks are dangerous, remember?). They use VSS for their web product but... they don't ever put comments in so it's impossible to roll back to a previous released version. They don't know about 'branching' so if they need to do an urgent fix they will apply the fix to the current in-development code base and attempt to patch up anything that hasn't been finished and deliver that as the fix.
  2. "The Database. I looked at the SQL Server database they have behind their web product and asked 'How is version control done?' The exact response (not a single word of this is a lie):

    "'We upload a version of the database to one of the customer websites and if it works we gradually copy it over to the other customer websites. We don't install it on all of them so that if we need to look at an older database version we know which customer website will have it and we just copy that back.'
  3. "Because of (1) and (2) it is impossible to reproduce versions of compatible database and web software versions.
  4. "Version control: They only have four versions of software:
    • "Dev1: This is the version number of any software that is currently in development.
    • "Dev2: This the version number of any software that has been 'finished' but not yet installed anywhere. So, when you finish work on 'Dev1' it automatically becomes 'Dev2' by virtue of the fact that you've finished work on it.
    • "AlphaTest: If you copy a piece of 'Dev2' software on to a live server it becomes 'AlphaTest' version (but only if you copy it into the directory 'D:\AlphaTest'). Note: this is not referring to the installation of the software, merely the copying of the software into the aforementioned directory.
    • "BetaTest: If you install something from AlphaTest into a customer site (and it works) you then copy back from the customer site to the BetaTest area (D:\BetaTest), overwriting the old BetaTest version. From then on all sites are installed from BetaTest — unless of course there's a newer AlphaTest version (indicated by more recent timestamps on the files in the AlphaTest directory).
    "What may not be apparent is that the BetaTest version from, say, November 2007, is not the same as BetaTest version from, say, December 2007. So, if you say 'What version is installed for customer X' the response is usually something like 'They've got BetaTest from November 2007... oh hold on, I think they had an upgrade in January... what's that? They had one in February? Oh... hold on, I just need to check the timestamps on the files.'
  5. "As there is no email all communication is via word of mouth or you have to write a memo, print it out, and then walk around handing out copies or leaving copies on desks and hoping people will see them and read them. I tried to argue for internal email using the argument that if I need to notify my team of something then it's a lot easier. He took me to one side, and in a fatherly way, told me the way to do that was to get everyone in to the conference room so I can tell them. I was tempted to tell him that having so many people in the same room was bound to help spread any viruses that might be going around but I thought the irony might be lost on him. Or that he'd sack me.

Amanda has been on the job for a few months now, and already feels that her retirement is overdue. Perhaps she should email her official resignation — once the email PC is free, that is.

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