One of the most famous tech workers in American fiction is Homer Simpson, though we don't necessarily think of him as such. Homer is the Safety Inspector at the Springfield Nuclear Power Plant, and his job involves sitting in front of an impressive-looking control panel. And yet we get hints that Homer's job could be automated. In one episode, he is replaced by a chicken who pecks at the buttons; in another, a brick dangling from one of the levers fills in for him. In "King Sized Homer," having already secured permission to work from home, Homer gets a drinking bird to replace him by hitting the "Y" button on his keyboard at regular intervals.
While Homer is an extreme case (and also a cartoon), many IT workers sometimes have similar sinking feelings that the things they do for their job could be totally or partially automated -- a feeling exacerbated by the fact that they are, after all, working on computers. And yet there are a lot of processes that still get done manually, especially where it turns out that the easiest way to get disparate computers to talk to each other is via a human intercessor. For instance, Lexi Hale, who used to work in IT for a large school district, found herself on two- or three-person teams that had to make identical system changes to each of the district's many Macs by hand. Eventually, she convinced her bosses to use Apple Remote Desktop to do this job. But when it came to changing individual student passwords, well, she had to send an email request to someone at central IT downtown -- and it was hit or miss as to whether they'd respond.
We talked to five more techies who've had to grapple with these frustrating situations -- some of whom actually figured out how to automate their systems, and others who just kept hitting those buttons. (We've provided anonymity to a few worried about making their current or former bosses mad.)
The zombie spreadsheet
In the mid-'90s, Alan De Smet was in college and got a temp job over the summer, working for a division of GTE (which would soon merge with Bell Atlantic to become Verizon) that installed trunk phone lines in new residential subdivisions. The work orders were tracked on a mainframe system that was out of date even then; incomplete work orders were also tracked in a separate spreadsheet. How did the data get from the mainframe to the spreadsheet? That's where Alan came in.
"Once a week I would log into the mainframe to run a report on the work orders. The report would print 50 or so pages of job summaries," he said. (It was printed on "the most bad-ass laser printer I've ever used.") "I would then load up the spreadsheet (Lotus 1-2-3 under DOS, or something similar) and compare the spreadsheet to the printouts, updating the spreadsheet when there was a discrepancy, usually because a new job had been added or a job had completed. The resulting spreadsheet was saved to a NetWare file server. I don't know for sure, but I've always suspected that no one ever actually looked at the spreadsheet. I wonder if it was a temporary solution that everyone forgot why it existed, so it continued on, zombie-like."
This wasn't Alan's only job: he also had to find any work orders that were due within the next two weeks and push them back an additional week -- with the upshot being that, according to the system, every work order would always be more than a week away from completion. "I know there were work orders I pushed back all summer. Some jobs did complete, or at least they disappeared from the report I was working from. I have no idea if the due dates were being used to prioritize jobs, but I'm confident that the due dates weren't useful for predicting when a job would be done." This too could've been easily automated, but maybe doing that would've made everyone admit what a sham the whole scheduling system was.