“But the greatest thing by far is to have a mastery of metaphor. This alone cannot be imparted by another; it is the mark of genius, for to make good metaphors implies an eye for resemblances.” — Aristotle, The Poetics
It is a trivial observation that software programmers use a lot of metaphors. All professions are obliged to invoke metaphors in one way or another, but in software programming I think the program is so extensive that we are not even aware of the fact that creating metaphors is our primary job. We are only ever immediately aware of the metaphorical character of our profession when we use similes to explain technical matters to our managers. Such-and-such technology will improve our revenue stream because it is like a new and more reliable conduit for information. It can be combined with sundry-and-other technology, which acts as a locked box for this information.
When speaking with technical colleagues, in turn, we use a different set of metaphors when explaining unfamiliar technology. We say that “Ajax is like Flash”, “Flash is like instant messaging”, “instant messaging is like talking to services in a SOA”, “SOA is like mainframe programming”, b is like c, c is like d, d is like e, and so on. Every technology is explained in reference to another technology, which in turn is just a metaphor for something else. But does explicating one metaphor by simply referencing another metaphor really explain anything? Is there a final link in the chain that ultimately cascades meaning back up the referential chain?
I have occasionally seen these referential chains referred to as a prison house of language, though perhaps a house of mirrors would be more appropriate in this case. We work with very complex concepts, and the only way to communicate them is through metaphors, even when, as in a fun house, the only points of reference we have for explaining these concepts are other concepts we find reflected in a reflection of a reflection. This metaphorical character of our occupation, however, is typically hidden from us because we use a different set of terms to describe what we do. We don’t typically speak about metaphors in our programming talk; instead we speak of abstractions.
Not only are abstractions explained in terms of other abstractions, but they are also typically abstractions for other abstractions. In Joel Spolsky’s explication of “Leaky Abstractions” (which is, yes, also a metaphor) we discover that TCP is really an abstraction thrown over IP. But IP is itself an abstraction of other technologies, which in turn may in themselves also involve further abstractions. At what point do the abstractions actually end? Is it when we get to the assembler language level? Is it when we get to machine language? Do we finally hit bottom when we reach the point of talking about electricity and circuit boards?
Again, I will posit (in a handwaving and unsubstantiated manner) that the main occupation of a software programmer is working with metaphors. Taking this as a starting point, it is strange that in the many articles and discussion threads addressing the question, what makes a good programmer?, poetry is never brought up. Overlooking Aristotle’s professed opinion that a gift for metaphor is something that cannot be taught, we might assume that if it is indeed something that can be cultivated, a likely starting point is through the reading and writing of poetry. It would be a pleasant change if in looking over technical resumes, we also starting looking for signs that prospective employees to BigTech.com also were published in poetry journals or participated in local poetry readings.
But perhaps that is asking for too much. The only other profession in which metaphors are applied extensively is in politics. Just as metaphors are called abstractions in programming, in politics they are called “framing”. Behind the notion of framing in politics is the assumption that certain metaphors are simply more naturally appealing than others. The proper metaphor will motivate one’s audiences emotions either toward one’s platform or against one’s opponents platform. The mastery of metaphor in politics, consequently, entails being able to associate one’s own position with the most emotively powerful metaphor into which one can fit one’s position.
One interesting aspect of the endeavor of framing is that a political metaphor is required to be fitting, that is the metaphor one uses to explain a given position or argument must be appropriate to that argument, and an absence of fitting will generally detract from the force of the metaphor. That there is this question of fittingness provides two ways to characterize political metaphors. There are metaphors that seem to naturally apply to a given circumstance, and hence garner for the person who comes up with such metaphors a reputation for vision and articulateness. Then there are metaphors that are so powerful that it does not matter so much that the circumstance to which it is applied is not so fitting, in which case the person who comes up with such metaphors gains a reputation as a scheming framer.
Determining which is which, of course, generally depends on where one is standing, and in either case we can say that both are masters of metaphor in Aristotle’s sense. However, because there is so much question about the integrity of metaphors in politics, it is tempting to eschew the whole thing. As wonderful as metaphors are, politics tends to make everything dirty in the end.
Which leaves software programming as the only place where metaphors can be studied and applied in a disinterested manner. In programming, the main purpose of our abstractions is not to move people’s emotions, but rather to clarify concepts, spread comprehension and make things work better. It is the natural home not only for mathematicians, but for poets.