View my profile


Beyond Expertise

Recently, I attended an interesting meeting looking at agricultural health issues, specifically influenza. For those wondering, human beings are only one of the species that can contract influenza and get sick. Farm animals are susceptible as well, particularly poultry and swine. The meeting was a gathering of immunologists, veterinarians, and agricultural specialists looking at how to address the chronic issues of influenza on the farm. We dove into the details involving the genomics of the influenza virus, how vaccines prompt an immune response, and how that response needs to spread through the whole body to provide systemic protection. Despite the advances we have made, the biochemistry of immunization is still a difficult science that features educated guesswork as part of the search for a solution.

As I sat and learned about the issues these experts faced, I began to see a pattern I've observed many times before. They were seeking a technical solution--a set of steps, compounds, or other methods from their toolboxes that could address the need for combating the disease. They dove far down into the details of T-cells, B-cells, and cytokines trying to identify the combination that would step toward a solution. It reminded me of my first success with computers, long before I had any "expertise" in the field. 

Very early in my career as an academic historian, I was working to turn my dissertation into a book for publication. Back then, personal computers existed, but cost was just out of my reach. Happily, the university where I was teaching had a mainframe with a word processing program. I spent months typing in my draft and revising it to prepare for submitting to a publisher. Once finished, I tried to get it printed on a high quality printer because submitting a manuscript on green-bar paper with a dot matrix printer was not going to be even considered. (How far we have come with electronic submissions these days.) 

IBM Selectric Typing Ball
I worked out a deal with the admissions office to let me use one of their letter-quality printers that they used to print out acceptance letters that looked like they were typed on an IBM Selectric. They were all connected to the mainframe because they used admissions  management software. So, I was able to stay into the evening to print out a manuscript that ran a few hundred pages. Problem solved!

Not quite yet. The printers jammed after a dozen pages and I'd have to abort the job and start over. The software was so primitive that I had to begin printing the whole file over again from the beginning. (Oh, the limitations!) After many evenings trying, I gave up on printing it out directly from the mainframe. Yet the problem remained. 

Fortuna smiled on me that summer when I agreed to teach for some extra pay. It was enough to buy a microcomputer and high-quality printer. I bought a Kaypro. The only question was how to get my text off the mainframe and onto floppy disks for my machine. Of course, the mainframe took a different size disk and had a difference format for its disks than my little 5.25 CPM diskettes could accept. So, after talking with everyone on campus who might be able to help me, I found one guy who was willing to try to help. (At this point, my wife usually asks, "Is this story going anywhere?")
The Kaypro II

I met him after work one day in the computer center. We tried hooking my little computer to a serial port on the mainframe and sending commands through a terminal emulator to the mainframe. (Sorry, in English, that means my computer would tell the mainframe what to do.) It didn't work. The technician helping me did not understand it and gave me very detailed reasons why this was impossible and that it should work. Those details went right over my head. I just kept thinking, "Man, I just want my manuscript. The reasons it does not work are of no interest to me." 

After several combinations of fixes with continued failure, he thought there might be an issue with the hardware connection and plugged in a diagnostic device that had a built-in keyboard. He could send the command to return with the file and see the characters streaming across a one-line display on the device. He then connected it to my computer to see if my machine could receive the commands and respond correctly, which it did with the characters streaming across his display in the other direction. So, there was no hardware issue on either end, but he could not see the path to a solution. He sat softly muttering as he thought through the possibilities of what could be wrong, going through the variations of the RS-232 communications protocols that had to be the root of the problem. 

My heart began to sink. I could only see me retyping the manuscript over many, many hours. (Remember, there is no auto-correct on a typewriter.) The thought filled me with the dread of wasted, redundant effort. I was desperate. Then, the solution come to me. I hesitated mentioning it to the expert because I didn't understand the nature of the problem we faced. My idea was naive, and who was I to propose it. But desperation drove me forward and I said, "Look, your device can send commands to the mainframe that it understands and return the text of the files. Plugging it into my microcomputer at the same time allows my machine to understand what the diagnostic device sends. Why not use the diagnostic device to send the command to the mainframe to download the file while it's also plugged into my machine which can receive the file?" 

He sat silent for a minute. His hands templed on the point of his chin. "Brilliant!" he whispered. "It could work." And it did. I walked away that day with the full manuscript on floppies and ready for a bit of clean-up before sending to a publisher. 

The lesson I took away from that encounter, is that sometimes the solution to a vexing technical problem has to focus on the goal and not the problem. Success is more likely if you can cross disciplinary boundaries to bring approaches and perspectives that escape the experts. I've tried to follow the experience of that encounter to continue to ask the naive question or make the simple suggestion when dealing with a complex technical problem. Sometimes it is not helpful and I can't avoid feeling the fool. But that is a small price to pay when it turns out to help a group see something with fresh eyes and then they figure it out.