Technical Change, Humiliation and the Macintosh
Jan 8, 2004 9:32 AM PT
A few years ago, the only IT system I wasn't responsible for at a multimillion-dollar company consisted of a SCO server with an ancient accounting application maintained by the remaining representative of the company that had originally sold it. At the time, I thought old Vitki (not his real name) was a fool and that his protector in the finance group was a greater one. But an Apple-related incident over Christmas left me with more sympathy for both of them than I'd ever managed to feel before. For just a minute or two, I was made to feel some of their pain.
Old Vitki was a COBOL guy who had signed up sometime in the 1980s with a group that had the western Canadian marketing rights for an American accounting package running on SCO Xenix. Although he claimed to be a programmer, he had become first an installer and then an owner more or less by survival. So he first learned a bit of SCO Xenix and later transitioned to SCO Unix when Microsoft stopped selling Xenix.
Since it was a COBOL package, report printing was a critical function, and he had to become something of an expert on printing those reports -- first to Centronics and other parallel impact printers, and then later to HP PCL lasers.
Sometime toward the end of 1995, however, "his" machine had died frequently enough that even the finance director agreed something had to be done. I upgraded it to a shiny new HP Pentium Pro with an unheard-of 32 MB of memory while replacing the printer with a 16-page-per-minute QMS laser printer to match what I had in other offices. These had TCP/IP network capabilities and big buffers as well as the ability to act as line printers, PCL printers or PostScript printers -- depending on the content of the incoming data stream.
Network Printing Harrumph
As a result, I had evolved a standard set of printer aliases that, when installed on the accounting department's new SCO box, let users print reports directly in each of our offices around the country without bothering with mail, fax, or e-mail transmission. Vitki, however, threw a major hissy fit when it came to installing "his" software on the new box. Not only was I so incompetent as to waste money on memory, but I hadn't even ordered or installed the parallel cable needed to access the printer. Worse, I'd been so stupid as to put the printer too far from the server to work with the cable he had thoughtfully brought as a backup.
When he, with protector and boss in tow, came to yell at me about this, I used my desktop Sun to print some pages from "his" SCO server -- and further infuriated him by pointing out that the rest of the company had been using network printing for several years. Worse, I followed up by showing them how printing accounting reports directly in the recipient's office could cut costs and turn-around time compared with mailing printouts or retyping them into Excel and e-mailing the files.
He never accepted any of this. He knew how to set up printers, and any nonsense about using /dev/null for output was harrumph, not just incompetent but outright evil -- never mind that it's standard practice, that it clearly worked or that installing a new emulation or page treatment consisted of running a simple interactive script. For more than two years he worked -- and billed by the hour -- until he had things just the way he knew they had to be, with a parallel cable, the printer locked firmly into PCL4 mode and no more network printing from his software, thank you very much.
Enter the Macintosh
I was uncomfortably reminded of this man's pain by something my wife did over Christmas. She asked me to print some Christmas photos taken with a digital camera at 24-bit color at 1,280 x 960 resolution. I don't remember exactly what I said. It was probably a vague promise to do it later, because I wasn't about to confess that I'd never tried to set up my QMS Magicolor to print photos -- despite having had it and The Gimp for upward of three years now.
She, of course, didn't let me get away with this. "Just let me use your printer," she said.
Well, I knew that wouldn't work, because it takes a lot to get the color sync just right and -- more importantly -- because a 1,280 x 960 image takes 1.06 x 0.8 inches to print on a 1,200 DPI laser if you don't interpolate a lot of the information needed for a full-page image.
So when she plugged her Mac into my office network, asked me for her password so she could copy the photos from my machine, and then sent a large number of them to the printer in one batch, I knew I had her. I mean, she hadn't even asked for the setup guide or done a test print, and I know she doesn't have a clue what the postscript rendering model is, never mind how to manipulate it.
The results were humiliating: The prints were superlative, my warnings silly and my expertise not just superfluous, but also obviously questionable. Vitki really could make a harrumph sound. I can't. But you understand why I was reminded of him; I mean, there I was vacuuming the house in disgrace before the dinner guests arrived instead of happily demonstrating great expertise playing with The Gimp and various printer settings. Harrumph!
Having been warned several times to "be nice," I enjoyed the dinner but sat out the vapid inconsequentialities that pass for conversation among the literacy, thinking instead about just how insanely great the Mac really is and making up a new resolution for this year.
I bought that printer used, and well before Mac OS X came into existence. Nevertheless, the Mac found it on the network, knew how to drive it and did a perfect job with absolutely no effort -- or knowledge -- on the user's part. It might not be an expert system, but it certainly has embedded expertise and demonstrates, I think, how open standards mesh with creative thinking to set the direction software has to go.
Embarrassingly, the incident also demonstrated the direction I have to go. So here's my resolution for this year: I promise to display a lot more empathy next time I deal with someone whose hard-won expertise has been rendered obsolete by technical change.
Paul Murphy, a LinuxInsider columnist, wrote and published The Unix Guide to Defenestration. Murphy is a 20-year veteran of the IT consulting industry, specializing in Unix and Unix-related management issues.