My own journey and interest in computers and metaphors began around my time as an undergraduate. I was working at the campus bookstore of my university and dealing every day with customers and their broken personal computers. I was well versed in fixing computers since I had been breaking, fixing and breaking again my own computers as well as those of friends and family. But what was new to me was dealing with customers and their broken computers.
I remember having a difficult time with explaining to customers what had been wrong with their computers and how I had fixed them. One day a colleague offered some advice to me after briefly watching me baffle my latest customer with non-nonsensical techno jargon. He told me to talk about the computer as a body and relate that experience to the customer. I was the surgeon and the computer was my patient. The CPU was the brain. RAM was short term memory and the hard drive was long term memory. The case was the physical container like skin. Things like keyboards and mice were limbs.
I thought this colleague's suggestions were nonsense but I agreed to play along. The next time I had to explain technical details about what I had done I used his method. It worked. Or at least the customer was nodding more and they seemed to be more at ease. They also stopped asking questions sooner and let me get back to my work. Whether or not they actually understood anything was irrelevant since I just wanted them out of my hair. I didn't care since the work kept coming and the customers were happy. What I had discovered was one of the most important principles of technical customer support. Some customers want to understand the root cause of a problem while others just simply want it fixed. But I control their understanding either way. I can make up whatever I want as long as it doesn't contradict something else I or another technician said. They will only question my understanding if the problem doesn't get fixed. I had discovered the power of language to shape reality.
After a while I began to question whether or not the customers really understood anything about computers. And if they didn't understand anything about computers than how were they able to even use them? It may seem like a very naïve question now. But at that time in my life I really didn't understand how someone could use a machine they didn't at least partially understand the inner workings of. I realized that through my use of a simple metaphor I had given the customers enough understanding to interact with computers and use them for the basic purposes. I had also given them confidence in their understanding of these machines and that had encouraged them to explore and learn on their own. But there was still something that separated my level of understanding from theirs. As long as they were conceiving of their computers only through metaphor they would never fully be able to realize the full potential of their computers. So for the moment at least I could still feel superior.
Then I started to look at how I gained my understanding of computers. And that's when things got strange. Because the more I dug into the linguistic artifacts of computing I could see nothing but metaphors. My original metaphor of the computer as human expanded to an examination of operating systems and their presentation. Why does every PC operating system boot up to a desktop or workbench? Why do we store information in files and organize these files into a hierarchical file system? What had files, desktops and filing systems been before computer operating systems had usurped their meaning? Why had these terms and not others been incorporated into computerese? And possibly most important of all, how was the meaning of these words changing after they were incorporated into computerese? My feeling of superiority was beginning to wane.
There's an old adage among computer folk about the guy who knows what he's doing. Put simply the adage states that the guy who knows what he's doing is a myth. My theory goes if someone actually knew what they were doing then we would have at least one piece of software that was bug free. Since we have no software that is bug free than there cannot be someone who knows what they're doing. The truth is we are all constantly learning and exploring new things. And most of that learning and exploring time is spent opening up metaphorical black boxes and poking around. Time must be spent trying to understand why the person who created some software artifact did it a certain way. And why they didn't take some specific circumstance into account which caused the program to fail.
There is a consistent line of reason applied to problem solving with computers. It flows from general to specific and from less technical to more technical. Let's say a user finds a bug in some program they are using. They will fidget with the program for a bit before giving up and blaming the program. If the software is supported this user will then call someone who should know more. This doubting support professional will ask questions about the problem to ascertain if the problem lies with the user or the software. If the problem is with the software then it will be sent to a programmer who must investigate and fix it. The programmer will hopefully be able to reproduce the problem and then start debugging it. She will first assume that the problem lies in hew own code and will look there. But failing there she will probably start looking at the libraries she is calling. Failing that she might need to look at the compiler, the operating system or hardware. But in all this searching for the solution a good problem solver will travel from general to specific. It would be foolish for the support guy to immediately assume the compiler is at fault. I've seen people make these kinds of assumptions and the reactions they receive from experienced folk are never positive.
The process that the programmer follows is actually a microcosm of the entire process. The entire process from end-user to programmer belies this general to specific flow. We first start with a user and make our way to a product generalist and finally to a product specialist. If the programmer who is assigned the problem cannot find a solution she will probably call in the help of other more specialized personnel. As we descend from general to specific each person in turn ends up having to investigate and understand black boxes that they may have only previously understood through metaphor. They must open smaller and smaller black boxes and poke around to understand them. Prior to the opening and poking they conceptualized of the black box mainly through others explanations of it. And those explanations from others were composed mainly of conceptual metaphor.
“The Internet[sic] is not a big truck. It's a series of tubes.”
Metaphors provide an easy and succinct way to talk about technology to non-technical initiates. They are a powerful force in rhetorical communications and their use or misuse can sometimes turn the course of a debate. This is especially true when the intended audience of that rhetoric are not very technically savvy. Just like I used metaphors to explain broken computers to customers, policy makers who cleverly wield technical metaphors shape arguments to their advantage. While policy makers who fail in crafting convincing metaphors or who underestimate their audience's ability to see through especially transparent metaphors appear as charlatans.
This was both Ted Stevens sagacity as well as his folly. He was right in assuming that the internet is 'not a big truck'. But he underestimated the negative response he would receive for calling the internet a 'series of tubes'. I personally think 'series of tubes' is a rather apt metaphor for the internet. But the need of relating a complex technical topic to technically inept policy makers was lost on most of the technically adept initiates who responded with vitriol to senator Stevens' remarks. The initiates didn't understand that the metaphor wasn't intended for them. And had they understood that most if not all of their understanding of computers was derived from metaphor they would not have been so angry. The rhetorical speaker must walk a thin line between using effective metaphors and getting caught by being too overt. A certain surreptitious use of metaphor is needed if the rhetorical speaker wishes to sway his audience. As most of the speaker's audience won't appreciate feeling overtly manipulated through metaphor. This is something that Ted Stevens failed to take into account in his metaphor for the internet.
Policy makers aren't the only ones who use metaphor to shape their audience's opinions of technology. Marketing and advertising of technical products including software makes heavy use of metaphors in its sales pitches. Metaphor is a powerful tool for advertisers but even more so for advertisers of software. You only have to look at the names of the many software products you have purchased or have installed on your own computer to realize this. The complete lack of physicality in software gives advertisers much 'wiggle room' for mapping a software product to a physical object. Do windowing environments really contain windows? Why do I look AT windows on a computer while I look THROUGH windows in my house? Shouldn't computer windows be called frames or canvases instead? The metaphor doesn't match at all the more you think about it. But we've gotten so used to looking AT windows on computers we're just comfortable with the language now.
There is simply much less physicality for a customer to relate to when buying software. A product such as shoes can only have so many metaphors applied to it because our understanding of shoes is rarely mapped through understanding of other products. Not only do shoes exist in a physical form that hasn't changed much in 2000 years but they are limited in a uniquely physical way. They have to fit on our feet. Every purchaser of shoes has a very good idea of what shoes do and what they want in a pair of shoes. And a shoe that won't fit on anyone's foot is not a shoe. When I go shopping for shoes I know basically what kind of shoes I want and what different kinds of shoes are available. If I want running shoes, dress shoes or work shoes I can immediately narrow down my search to which shop I look in and where in each shop I look.
This is not at all true for software. Not only are new software products being released constantly creating new categories of software. But the existing categories are already poorly defined. This messiness is easily exploited by software salesmen as an opportunity for defining what the product is. They don't want to just tell you how great their product is or how it compares to other products. They want to tell you what the definition of the product class is. And they want to define the product class in terms that make their product shine brightest. I have never had a shoe salesperson try and explain to me what a shoe is. Or for that matter try and explain to me what the purpose of a dress shoe or work shoe is. It would not be an effective way to sell shoes since we all have very grounded ideas of what shoes are. Any attempt to convince a prospective buyer of shoes that they just don't have the right idea of what a shoe is would be laughed at. This is absolutely not the case with software. Sellers of software routinely redefine the class of products they are competing against in line with their own. Differentiating ones product against competitors is a way to insure success and be noticed in the software industry. If you can differentiate by redefining your product class than you can control the conceptualization of your competitors' products as well as your own in the marketplace. Once customers recognize your definition of the product class as the right one they will want your product.
I was recently asked to evaluate 'knowledge base' software for the company I work for. I started by asking various people in my company what they thought a knowledge base was. To my dismay I received numerous different answers, some of them even contradictory. From these discussions I decided that what we were really looking for was a better search engine for our existing knowledge base. But as I began talking with different search engine providers I realized they all had different ideas of what a search engine was and what it should accomplish. You might think that a technology like search would have a clear definition in the marketplace by now. The different vendors of search engines should have all agreed on what a search engine is by this point. But this is not the case now nor do I suspect it ever will be.
Part of the problem is that search engines like any significant technology are a moving target. They are constantly changing and improving. So trying to nail down exactly what one is and what it should do is impossible. Our understanding of technologies like search is in large part defined by the market leader, in this case Google. And that gives them a huge advantage in selling their search solution since they can dictate our understanding of what search is. No one will be able to usurp Google's position in search until they are first able to redefine our understanding of what search is and what it's function is. I don't expect any up and coming shoe manufacturer to be desperately looking for a new definition of shoe. They are most likely focusing their efforts on things like style, materials, and cost cutting. The conception of shoes that I have today will most likely not change in my lifetime. But I doubt that my current conception of a search engine will be the same in 10 years.
“Large digital machines[sic] are made up of 'active' organs and of organs serving memory functions-I will include among the latter the 'input' and 'output' organs...”
John von Neumann
The above quote is taken from “The Computer and the Brain” by John von Neumann page 29. “The Computer and the Brain” is a collection of lectures von Neumann was working on before he died in 1957. This book and the rest of von Neumann's work on computer design forms the corpus for what computer scientists now call the von Neumann architecture. And the von Neumann architecture forms the conceptual basis for everything that we now conceive of as a computer. Some of the ideas outlined by von Neumann are so basic that it's easy to take them for granted today and not even recognize that they were once new concepts. But von Neumann and other scientists working on ENIAC conceived of these terms before they existed for us to take them for granted. So we should be interested in which metaphors von Neumann and others used to discuss their work concerning the design of computers. But more importantly we should be interested in what metaphors they used in order to conceive of their designs.
Von Neumann uses the word 'organ' to describe what we would now identify as elements of a block diagram for a modern computer. But the word 'organ' only has 2 distinct definitions in English. One is a musical instrument while the other is a differentiated part of a biological 'organ'ism. I do not think von Neumann wanted the reader to conjure an image of a pipe organ while reading this explanation. Instead we should assume that he means the biological organism definition.
The question then becomes, did von Neumann allow his understanding and conceptualization of the human body to influence his early conceptualizations and eventual designs of the computer? OR Was he merely using the metaphor of 'A Computer is a Person' to explain his previously conceptualized notions of what a large digital machine is? From what we know about how humans conceptualize, understand and communicate we can be fairly certain that von Neumann was at least somewhat influenced by his understanding of the human body in his conceptualization of his computer. We can say this with such certainty since it's practically impossible to communicate about something in a way that doesn't influence your conception of it. In other words it would be almost impossible for von Neumann to choose words derived from an understanding of the human body to explain his computer if he didn't already understand his computer through human terms. We can probably then assume that other concepts of the human body were taken for von Neumann's abstract design of our modern day computers. Some of them might have been taken consciously while most others were probably subconscious design choices that von Neumann wasn't aware he was making at the time, but had extended implications that still influence us today.
One possible implication is the recurring question of when will the intelligence level of machines equal or exceed the intelligence levels of humans? This event is called the singularity and when and if it will happen is a hotly debated topic for futurists and computer scientists. For me the fact that we debate this question at all is a lot more interesting. Why do we ask if humans and machines will ever reach intelligence parity? We never asked this question before computers. No one ever wondered if machines could reach human levels of intelligence after the invention of the bicycle, the automobile or the dishwasher. Could it be that our natural penchant for comparing computers to humans causes us to wonder if a computer can ever become human? Is our subconscious use of the metaphor 'A Computer is a Person' influencing us to consciously attempt to make it a reality? Did von Neumann put us on the path of predicting the singularity by conceptually basing his initial architecture for the computer on humans? How much does our conceptual understanding of ourselves influence our design decisions? Are we acting out a desire to reproduce by designing machines in our image or are we maybe playing at god instead?
Looking back I see now that my journey into metaphors and computers has been ongoing for some years. But it is only recently that I became consciously aware of it enough to write about it. My initial instruction as an undergraduate in the 'A Computer is a Person' metaphor by my colleague has led me on a journey to grasp the root of that metaphor. Did it start with von Neumann when he wrote “The Computer and the Brain”? I doubt it. How long has humanity been making 'creatures' in their image? Mary Shelley's Frankenstein and Jewish folklore's Golem are just two of the examples I can think of. And perhaps we would gain more understanding of the coming singularity by studying our repeated incarnations of the Golem than by examining anything scientists are doing today.