Stop Using Metaphors

A strong opinion on this subject:

EwDijkstra: "The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity." (EWD 709)

See: "On Anthropomorphism in Science" (EWD936) http://www.cs.utexas.edu/users/EWD/transcriptions/EWD09xx/EWD936.html

A strong counter:

PeterMerel: "Even the most mathematical terminology, informing a human, creates a form in a human. If that form is to be of use, it must express as a human behaviour. Therefore all computing terminology we can communicate is inherently anthropomorphic."

This is equivocation on "anthropomorphic."

CostinCozianu: "PeterMerel is strongly advised to peruse the dictionary. Gee, it's open season again at American Idol, what a funny coincidence. "

Dictionary flames? Heh. Point is that all forms of our experience are embodied and expressed by humans. Consequently "anthropomorphic" is a poor word choice. What you and EWD are denigrating is pedagogy. Consider an extremely pedagogical treatment like WhoIsFourier. Chockablock with metaphors and anthropomorphisms, wildly successful, and written by children for children. Would you accuse its editors of professional immaturity? How about the child authors themselves? Their teachers? Who?

Gee, Peter. You have first to speak understand the same English as Dijkstra. And Dijkstra uses the fairly common meaning for anthropomorphic, which you can check at dictionary.com, but you dilute that in order to construct your StrawMan. If you want to criticize, make sure you criticize what Dijkstra, in this case, has actually said, not what you invent the meaning of his words to be. Now teaching children some basic intuitions behind physics and maths, that's all nice and dandy, thanks for the reference, by the way cause I have a wildly curious son myself. But in order to claim that as counter-examples to Dijkstra's assertion, you'd have to pretend that the children that go through those books are in the same league with respect to professional maturity as those Dijkstra was referring to.

I think your son will love the Hippo books. And thanks for the links - in context I see your point.

I followed both the EWD936 and 709 links to make certain I understood. I didn't find your exact quote above in 709, but suppose it's in his cannon somewhere nearby. Anyway, to use one of EWD's examples, when the networker spoke of the packet "wanting" to go from A to B, I think that's a reasonable professional shorthand for the networker himself "wanting" the packet to go from A to B. Likewise I see no immaturity in anthropomorphizing the amoebae dividing; I think EWD's desire for such asceticism is fairly refuted by ChuangTsesFish.

And anyway, aren't you using Djikstra's statement on anthropomorphic terminology as a metaphor for your own on metaphors? ;-)

I started this page long time ago and it was refactored times and times again, so the message got somehow lost or at least as diluted and byzantine as to no longer having value. I later found EwDijkstra's strong opinion and I put it on top of the page, but I know a lot of people whom would take offense or exceptions with that. So I take the liberty to restate it here on the top of the page. Shoot me if you don't like it. -- CostinCozianu

I didn't mean stop using metaphors in absolute terms, certainly metaphors have value when not abused. The point was to StopUsingMetaphors as substitute for real understanding. Metaphors are nice and dandy in essays, in pedagogical settings to give your students a nice kick into a subject but they can never be used as substitutes for real definitions of concept, real reasoning over the properties of a piece of code, and all the concrete stuff that we deal with in software.

Metaphors have become more and more prevalent as substitute for real knowledge about software. And the contention is that real knowledge about software systems it is in nature mathematical (ProgrammingIsMath). People may choose to pursue in software design such things as correctness guarantees, deadlock-free, progress and liveness, reliability (make a reliable system form unreliable parts), data integrity and all kinds of concepts that you don't need metaphors to describe. Or people can pursue SoftwareHasShape, QualityWithoutaName and all the other philosophical voodoo that has become fashionable lately (software is group poetry writing, what a nice metaphor and what a piss poor way to organize a team of pragmatic engineers). Those terms don't suffer any concrete definitions and are defined only metaphorically. A concept that can be defined only metaphorically is more often than not a delusion and not real knowledge. The lack of concrete definitions and of quantifiable and formalizable properties is a very strong sign that you don't quite understand the concept, phenomenon or whatever you're "metaphorizing" about.

To taken a concrete example, some people have claimed that ModelViewController is one of those design patterns has that QualityWithoutaName and is otherwise a very good pattern, and it recently permeated certain web application patterns. However when it comes down to it in your average design patterns books, you can observe that the code written by its advocates suffers from significantly more lines of code than would be normal, a certain type of "higher order" redundancy (don't worry I can explain this metaphor in concrete terms), and less than stellar performance. Nevertheless the figurative discourse goes on that it organizes your code better, and the MVC code is more "inhabitable", it has that "je ne sais quoi". For me as software engineer and kind of responsible for software designs ("architect" - another lousy metaphor we live by), I choose that all these figures of speech are not worth much (they are worth something but they are at the bottom of the stack). I'd rather spend my precious little time for education reading EwDijkstra and not ChristopherAlexander, DavidParnas and not MartinFowler.

Another recent trend that contemporary books on software are full of metaphors, and I read pages after pages of prose and code that definitely feels like prose. Nowhere in sight is any mathematical property about the constructs the authors claim to do you good.

In practical settings, I hear ideas from my colleagues who ask my opinion, and the most common situation is that an idea is first described in figurative speech (mostly metaphorical). The best exercise you can do with software design ideas is to extract them from their metaphorical setting and try to reason on them as concretely as possible. What properties can we deduce of this design? Can we prove anything of it, can we find limit situations? More often than not people are initially frustrated by my demands to descend into concreteness and precision, but at the same time they will recognize bad ideas sooner rather than later. Put a bad idea that sounds metaphorically nice in your software and it will bite your ass in very concrete terms: the damn box will stop responding, or you'll have piss poor performance, or you'll end with 1+1=3 right in front of your boss. Metaphors can only go that far, beyond that far (which in my opinion is not very far) you have to StopUsingMetaphors.

An even stronger claim than StopUsingMetaphors belongs also to EwDijkstra: avoid OperationalReasoning like the plague. And you have to think that he meant operational reasoning as a mathematical activity, whereas in real life people do their operational reasoning in metaphorical terms:

I find it both less desirable and having negative consequences whereas default "do nothing" behavior is better. It's also an extension of thinking as objects. First we learn to think as the thing we're programming: "be" the widget. Then we can learn to "not-be" or be nobody, be space. Nothing there, so nothing is done. Another way to think about it is: is it "ok" to talk to a wall?

While operational reasoning has proved valuable lately and has been rehabilitated, in concurrent programming and otherwise non-deterministic settings, Dijkstra's advice still holds.

What is "OperationalReasoning"?

Note: The following complaint is about creating new metaphors. It is still ok to run your program, fork your source tree and surf the net.

Note to note: I know I'm being picky, but run your program isn't a metaphor (my dictionary tells me that run can mean to be functioning, or to put or leave something in a functioning mode). fork your source tree isn't really a metaphor either, as fork can mean to split into two or more branches

Those are simply metaphors that happen to have dictionary entries.

I've often thought that this page is perhaps the most asinine on the Wiki. Now I'm sure of it. How do you think these mathematical terms get defined? They're almost always originally derived from METAPHORS. Let's go back to "Fork your source Tree". OK, so I'll understand about "Fork" but what about "Source Tree"? Oh, you'll lead us back to the mathematical definition of "Tree"... But where did that come from? Why don't we call a recursive branching structure a "Shazbat"? It's because TREE evokes something to us...something that a purely arbitrary technical term does not. And WHERE do you think your definition of "run" came into being from? Did you trace the etymology of that usage? If so, you'll probably find that it really is a metaphor to actual, physical RUNNING of the multi-legged variety. Think about it... "Will that horse run?"..."Will this horseless carriage run?"..."Will this computer run?"...

I guess my picky note above came out wrong. I totally agree that these terms surely came from metaphors in the first place. But when a word takes on a new meaning, presumably from being so widely used metaphorically, then doesn't the phrase cease to be a metaphor? Isn't it now just a regular use of the word? Apologies if I'm wrong here, I just thought there should be a distinction.

For what it's worth, I also didn't mean to come off sounding "anti metaphor" (far from it). StopUsingMetaphors seems to me about as useful a piece of advice as "stop using vowels". My communication skills aren't always the best, so I'll use anything I can to help me explain myself; metaphors are invaluable for this.

Human communication is impossible without metaphor. Unless you relate new concepts to similar concepts someone else already understands, then you'll never communicate. We're PEOPLE not computers, darn it! Admit it and act like one - just get over it...

I strongly agree with this. You are throwing the baby out with the bathwater here. Unless you want to be completely misunderstood and ignored by those around you, you have to communicate with people, i.e. homo sapiens whose brains evolved to think spatially and in terms of forces and other stuff that mattered when roaming the African savannah.

Every sentence that comes out of our mouths reveals how the mind works - ideas (nonsensically) going from "here" to "there", "seeing" what people mean, imputing desires into inanimate objects. This is not some imperfection to struggle against (or if you see it that way, it's possibly the most futile struggle you could undertake), but a common ground which one can exploit to more effectively communicate with other homo sapiens.

The message is so wrong and such bad advice that it sticks out like a sore thumb on this Wiki. Clearly an AntiPattern.

Plus, this is the last thing software engineers need to internalize: historically we've had problems communicating our ideas (or communicating period). Casting engineering solutions in more mundane and impenetrable formalism for its own sake is simply regression. -- SteveConover

Please stop using metaphors. When you find them nice and you can't help but use them, please further elaborate the 'metaphorical' concepts in terms of concrete description, definitions, mathematic-like reasoning. Very often metaphors are a sign that you don't have a clear concept, therefore they shouldn't ever be used in patterns, because patterns are supposed to communicate an objectively good solutions to a specific class of concrete problems.

I think it can never be said enough. Please stop using metaphors in order to define concepts or to do reasoning about software development.

Stop using any literary trick in defining concepts (personification, parables, epithets and please add to the list).

The original author of this page is quite hoist with his own petard. The literal meaning of "stop" is to block or cease motion. Therefore the title of this page should literally be read to mean "cease motion by means of metaphors", in other words, Metaphors are brakes.

uh, this sort of egregious misinterpretation of language is only forgivable if you're Babelfish. You're not Babelfish, are you?

From Merriam Webster (www.m-w.com):

stop: 4a. to cause to cease. (check, suppress). 4b. Discontinue.
use: 2. to put into action or service : avail oneself of : employ.

In other words, "stop using metaphors" means "cease employing metaphors". A meaning that's fairly easy to infer from context. -- FrancisHwang

You want it both ways then: to reject imprecision in linguistic constructions yet allow interpretation and inference from context. The alternate meanings of "stop" are there because the human brain found that the literal physical stop is a good metaphor for cessation of all sorts, including those not involving the physical world. See "Metaphors We Live by", George Lakoff, Mark Johnson, ISBN 0226468011

I challenge anyone to go more than two sentences without using metaphors. You use them without even thinking. They are built into the phrases of our language and every other language because it's how our brains are wired.

I don't know why you think I'm the person who wrote this entire page. I certainly don't have a problem with linguistic imprecision - I'm a freelance writer, for goodness' sake - but I will say that I do think metaphors can be overused here, often leading to murky, counterproductive arguments. That's why I wrote MetaphorSmackdown. And that's also why the work I've been trying to do on refactoring a bunch of "architecture"-related pages - CanAnArchitectureEmerge, ArchitectingWord, ChiefArchitect - sometimes feels like I'm shoveling water. -- fh

Stop using verbs: they move around too much. Adjectives: they aren't really descriptive and overused can lead to excess commas. Don't even get me started on adverbs, they just modify verbs and if straight verbs are bad, adverbs are even worse. Nouns, especially abstract nouns, are a problem as well. If we eliminate the verbs, maybe the nouns will be better.

To Paraphrase... Avoid metaphors like the plague. :-)

In other words: Similes are OK (?)

If you ever find yourself writing something like

No, the girders are the design, and the rivets are the source code.

... then your discussion is now officially useless. -- FrancisHwang

Some circles of software developers (e.g., the ObjectOrientedProgramming circles) are prone to using metaphors. I don't recall developers habitually standing around in circles, or seeing a circle of ObjectObjectOrientedProgramming?

There are times when using a metaphor detracts from the goal: communication.

I contend argument is war that every time a discussion about software development and/or computer science leaves behind some concepts defined only at a metaphorical level, the meaning and usefulness of those concepts are lost. Metaphors can serve as a good introduction sometimes, but 'metaphoric' things need to be elaborated into concrete, clear concepts .

When they are too vague/subjective:

Metaphors often mean different things for different people. Thus they can end up communicating very little.

Examples:

When they are inaccurate (A.K.A: Flawed Analogies):

If you have a metaphor that has fatal flaws it is going to cause confusion. Sometimes there are no actual flaws, but the initial impression is confusion. If the concepts require too much additional explanation, they should be used carefully.

Examples:

Technically BasketballMetaphor is a parable. Many patterns containing the metaphor in their title are parables. This further demonstrates the danger to operate with fuzzy concepts.

When they make you look silly

'There are people who say that the unbridled use of metaphor causes one to look imprecise and non-mathematical. This accusation is aimed against the ObjectOriented community in particular.'

'If you're in an environment where being silly is bad, you will want to be doubly judicious.'

You have badly refactored my text, and the intended meaning was lost. Those people do actually have a good point to make about a very important trend in the discussions on OO software development and patterns!

My intent was not to get rid of a possible source of annoyance, I couldn't care less for that, but to draw something useful from an objective criticism. -- CostinCozianu

Your point is valid. Maybe the use of metaphors is encouraged too much, at the expense of the goal (communication). But why replace one bias with another? Instead, let's encourage that a good choice should be made in each situation.

That's a very valuable observation, ThankYou. As a result I refined what I asked for, and I admit literary tricks are good insofar as they don't make it into defining concepts, reasoning on software development issues, and making value judgments about software development. Do you think this restriction is fair enough? -- CostinCozianu

Another point: Do we fully understand everything there is to know? Are the things that we don't fully understand worth talking about? If so, is mathematically strict terminology still the best choice?

Of course we don't know everything. Of course it is worth talking about what we don't know very much about. However, very often literary tricks are present into patterns and definitions here on wiki. Just one more example that I remembered is ComponentDefinition. So, we shouldn't formulate patterns on things that we don't have knowledge enough at least to give them a concrete definition. We shouldn't give advice on software development issues that we don't fully grasp, so far that a metaphor is the best thing we can use to describe them. And things like that.

Contributors: CostinCozianu, AndyPierce, KyleBrown and a WikiGnome who is trying to RefactorEmotions - and almost diverted the original intention because I caught him emotionally involved - that's the danger when we talk about metaphors, they are emotional by their nature :)

As a matter of fact I meant stop using ANY literary trick - metaphors are only the most common evil on Wiki. -- CostinCozianu

Please elaborate, possibly on a page of its own... I'm interested.

Personification is also a bad thing, that many people are very fond of.

Don't personify computers. They hate that.

I learned literary theory in high-school, in my native language, therefore my terminology in English is approximative. But one very common example in OO discussions is the use of personification. Since objects very often model things in real world or a virtual world (Account, Customer, Product, Order, Item, Shipment) the discussions on particular cases or even on OO in general tend to associate those object or virtual concepts, with an independent will and power to perform action. In more formal expressions of OO concepts, there is no such thing, and it is very beneficial to change the:

From here a majority of OO people tend to forget that the fundamental notion of type is a set of values, and wrongly equate type=class and value=object=instance of class, and further they put a bad accent on object identity, because instances are very close to the literary idea of personification, and they think it's far better to reason of a system in this terms.

Instances are quite justified by a more formal notion of abstract state machine, but this is not even mentioned in the discussions, instead an instance is often discussed as an independent actor on the OO model scene.

Another bad consequence from this 'personification' is that you have the famous ObjectRelationalImpedanceMismatch, which is essentially a false problem. Unless we stick hard with the notion of instance as a primary concept, while the relational model operates only with and sets (relation is a special kind of set). [Claim: ObjectRelationalImpedanceMismatchDoesNotExist.]

And also you get some kind of intolerance and ObjectPurism, with respect to languages and systems who don't proclaim the instance as their primary concept.

I'd like you to give some better explanation as to why the ObjectRelationalImpedanceMismatch is a false problem, and how exactly not having instances solves it? -- KyleBrown

RE: "a majority of OO people tend to forget that the fundamental notion of type is a set of values"

Hmmm... Perhaps I'm starting to see the kernel of disagreement here: For me, the most fundamental description of OO is that it combines behavior with state. (methods + values) So I would not agree that the state of the system is the only and most important view from which to understand it. Indeed, I would say the opposite: The behavior of the system, as visible through its interfaces, is the most important for understanding the abstractions it implements.

Yes, I know all about automata theory, and the abstract mathematical notation of state machines. But the fact that the machine has a binary state does not make listing the binary state the best way to make it understandable to human beings. -- JeffGrigg

Jeff, I was talking about types, not about classes. I agree that in general object = data + behaviour where usually by object we mean instance of a class. Even the latest assertion (object = instance of class) is not necessary valid in all OO systems and languages. Please note that here behaviour is really a metaphor and this leads to a great deal of misunderstandings and often intolerance for something that's different. We really need to define what we consider behaviour.

This is illustrative of the dangers of using metaphors. Otherwise, I contend there are several equally valid theories and models on ObjectOrientedProgramming. Let's discuss them there, without metaphors, of course.

To call behaviour a metaphor is begging the question.

Also, the parable is very often used.

I am a (poor) mathematician and a (bad) writer and a (humble) software developer. I can describe many of the systems I write in terms of information theory, mathematics, etc., especially these days when I just move bits around. Nonetheless, I recognize that programming languages are for people, not computers, so I make my programs readable. Metaphors are more expressible than mathematics, so I use them. There is no easy way to describe a thread (a metaphor) reasonably without metaphor. You try it. You get reduced to TuringMachine expressions. Now try to describe calendar software without using metaphors. Why bother?

Actually, what happens is you reduce software to symbol manipulation, squeezing the semantic meaning out of it. Since I write software to achieve a real world goal, a lack of semantics is impossible. (Contrast GeneticProgramming, where there are no semantics.) If you read the philosophy of mathematics, especially the linguistics of mathematics, you'll see the same argument. If a theorem has no metaphorical meaning, then there can be no such thing as an interesting theorem. All theorems become equally (and thus not) interesting. -- SunirShah

Software is symbol manipulation - sometimes with concrete results. A symbol without a referent is meaningless. -- DirckBlaskey

Well, StopUsingMetaphors doesn't mean we have to start talking in equations or in terms of computations on Turing machines. I asked please use mathematic-like, clear, concrete concepts. More important is to use mathematic-like reasoning like for example: 'This pattern is good, because it solves this objective problem in this concrete way.'

If you say to me that a thread is a sequence of instructions that is being performed independently from other sequence of instructions, scheduled by a specific algorithm, than it is clear to me (approximately). How do you define a thread in metaphors then?

Primarily I was talking about conversations between software developers, about sharing experiences, trying to draw using ink or pencil? some conclusion, patterns etc. Metaphors stay in our way, because we should be capable enough to speak in concrete chat rock and binding? terms, and even to formalize when needed.

On the other hand, in conversations with the end-users it is equally harmful to use metaphors. They might help start a conversation on the subject, but in the end we have to have very clear concepts that we share with the end-user. A metaphor by its definition is subjective, and open to various interpretations.

And another thing, the same metaphor might actually mean very different things in different cultures.

You might say that the difference between a "mere user" and a software engineer is the ability of the engineer to transcend metaphor (or should I say un-transcend it) in order to yield machine-realizable concepts, and eventually a running system. You might also summarize this by saying MetaphorDoesntCompile?. -- WaldenMathews

Cognitive science holds that metaphor is fundamental to human thought. E.g. without metaphor, mathematics has no meaning. So it doesn't make sense to ask for metaphors to be replaced by mathematics!

Would you mind being more concrete in your criticism? I didn't say replace metaphors with equations. You can try yourself the principles I tried to define here, and be more concrete, not abstract and fuzzy. Metaphor might be fundamental to human thought, even if I have a hard time recognizing cognitive science as a science, but I was talking here about human communication and human exchange of ideas, particularly in the field of software development

I like metaphors. They are okay when you see them as tools for understanding rather than substitutes for understanding. -- MichaelFeathers

Well, to someone who subscribes to the opinion that metaphors are understanding... they can't be "substitutes" for the "real thing".

Now, irrespective of that line of argument, it seems to me that we are too quickly equating "metaphorical" with "imprecise". Why should the use of a metaphor necessarily project a fuzzier picture than the use of descriptive language?

Taking up Walden's gauntlet - "a thread is a sequence of instructions that is being performed independently from other sequence of instructions, scheduled by a specific algorithm". I'm reasonably sure that one could find fuzziness in "sequence", "instruction", "performed", "independently", or "scheduled" if we looked hard enough. (I'm a wimp for not including "algorithm" in the list... so sue me.) That definition as it stands is also descriptive of a number of other things, from operating system processes to assembly lines in a factory.

I'm not sure that metaphor underpins all of human understanding; but I'm nearly convinced that "fuzziness" is the hallmark of all language, no matter how "mathematically" precise. To talk is to run the risk of being misunderstood.

For the hardcore, see a weird paper on "Metaphor and Metonymy in Object-Oriented Design Patterns"

http://www.mcs.vuw.ac.nz/comp/Publications/CS-TR-01-7.abs.html.

Not clear the authors understand either Metaphor, Metonymy or OO, but the cows in the first figure are cute!

Communication is hard. It generally takes many attempts to learn how to get a message across. I remember the early days of XP on this wiki, as Ron (and Kent, but mostly Ron on this wiki) learned how to talk about XP. XP has lots of metaphors, such as the one of the customer "steering" the project and the one about one member of a pair "riding shotgun". These are natural and fit well, though they do not say everything there is to say about customers or pair programming.

Metaphors can be good, and they can be bad. It is easy to make bad metaphors and hard to make good ones. When you see a metaphor that you don't like, you shouldn't say StopUsingMetaphors, you should say "That metaphor doesn't help me at all" or "That is a bad metaphor". Authors need help in improving their story, but eliminating metaphors will not make them better. -- RalphJohnson

Dogma is no substitute for understanding. Xxx is bad, don't use it. Huh???

The truth is language is very bad at communicating, especially either very philosophical or very precise concepts. Metaphors are simply a method of establishing a frame of common experience, from which we can then proceed.

Plato talked about metaphors in the Republic. Basically, most people can never look at reality straight on. The goal of the philosopher king is to replace the misleading metaphors of the poets with metaphors that reflect reality. We are not linear creatures and metaphors are easier to understand and apply than symbolic reasoning.

"The truth is language is very bad at communicating" is a meaningless statement. Communication is by definition use of language, or isn't it? And metaphors are a fundamental thing, statements of the form "this is like that, except ...", you only have to remember the "except" part. Which is always there, btw. Even if we talk about self-identities, there are exceptions. You may say "a = a", but even so, what you are really saying is that "a is a, except one a is on the left side, and the other a is on the right side of the equation." Otherwise, the only way to express self-identity would be naming, "a", and even so, there is the fundamental distinction between the name and the named. I refuse to classify mere existence as a form of communication. -LasseHp (feel free to delete.)

One of the principles of teaching (and communication is often that) is that you start at a commonly understood point and then build from there. Metaphors are usually phrased using commonly understood situations that also have common basic scenarios surrounding them. When one who is totally familiar with a concept tries to teach (communicate with) another, the approach is dependent on the knowledge of the teacher (communicator) of just how much the learner (hearer) understands. The problems described on this page are more about the FailureToCommunicate?, than they are of the UseOfMetaphors?.

One communicates with another by consent. The listener must say yes in one form or another to the message passed by the sender. If this handshake does not occur, 1) the listener did not receive or hear the message, or 2) the listener did not fully comprehend or understand the message, or possibly did not choose to pass back to the sender a confirmation of reception or understanding. The communicator is left with the choice to either continue attempts to communicate using a differing approach, starting with something akin to "do you hear what I am saying?", then possibly "do you understand what I am saying?" When the reply is received, the communicator can then continue with the communication (depending on the response) with additional information, or elaborate or illustrate the information using other indirect methods (such as the subject metaphors or similar structures). One does not need to use metaphors in communicating with peers, but when communicating with those less knowledgeable the technique can be helpful.

So when I hear the response StopUsingMetaphors, I hear a strong yes to reception of the message. If I do not detect a yes to the passing of information, I seek whatever method, including metaphors, to get the message across. I try to OnlySayThingsThatCanBeHeard. Do you understand?

It might be useful to try to figure out when metaphors are useful, and when they are not.

My first guess would be something like this: A metaphor works to crystallize a set of dynamics into one encapsulated concept. But if the underlying dynamics are not agreed-upon or well-understood, then the metaphor will be more harm than good. Perhaps it's related to OnlySayThingsThatCanBeHeard.

For example, I'm a big fan of this saying, which I think comes from FredBrooks:

You can't make a baby in one month with nine women.

The corollary to software-engineering is that software-engineering is not a process that can be easily divided and delegated among many people. Many programmers understand this. I really enjoy passing this on to ProjectManagers who are starting to grasp the scope of the organizational problem. I get a kick out of watching the smile of recognition, as a truth solidifies into something that can be held onto, and thus used to build other ideas.

But if I went to the president of my company, and stepped into the office with this saying, he'd look at me like I was nuts. And then if I tried to explain it, he'd come up with lots of reasons why my thinking doesn't help him out. Maybe we'd be able to continue the conversation from there, but I'd have to discard the metaphor very quickly if I wanted him to keep listening. -- FrancisHwang

A similar saying is along the lines of "The recipe for the cake says bake for 40 minutes @ 180 degrees. I can bake it for 10 minutes @ 720 degrees. The result just wont be edible." Again this is useful to demonstrate to Management that it's pointless making a deadline if the result is not usable.

What is missing is a link between the cake or baby being the work that needs to be done on the software project and the women or oven being the development team. Why is software development not like digging a hole or hammering nails into wood (physical activities where increasing the resource can reduce the overall time)? What shows that having 2 developers for 1 week is worse than having 1 developer for 2. As developers we all know this is true and we need to be able to demonstrate this. The only rationale I have seen is that there is an increasing complexity in the communication that needs to occur as you add more developers. However, using a componentized approach can alleviate this to some degree. None of this is apparent in the metaphors above.

A metaphor is useful when you use a well understood concept to explain a less well understood concept. Too many times I see metaphors used that are not understood to explain concepts that are well understood. One example of this is "software as manufacturing." I am sure many of us have had absolutely no experience in a major manufacturing environment and most related discussion is more about vague interpretations of manufacturing and provide no insight on software development. Only use metaphors that are well understood by everyone if you really want to make a point. -- WayneMack

However: "A newly invented metaphor assists thought by evoking a visual image," said Orwell, "while on the other hand a metaphor which is technically 'dead' (e.g., iron resolution) has in effect reverted to being an ordinary word and can generally be used without loss of vividness. But in between these two classes there is a huge dump of wornout metaphors which are merely used because they save people the trouble of inventing phrases for themselves." (from: http://www.economist.com/library/styleGuide/index.cfm?page=673913) -- AndrewQueisser

Metaphors are vehicles for communication. Once your communique has crossed the bridge of understanding, abandon them at will.

To ignore the power of metaphor is absurd. -- MichaelLeach

Old joke: "Don't personify computers. They hate that."

I think our poster has his terms mixed up. The problem is similes, not metaphors. But StopUsingSimilies? sounds like that David Byrne album from years ago.

Metaphor: The bootloader mounts the image file to a RAM disk before loading the remaining device drivers and kickstarting the daemon.

Similie: Our information superhighway will be like an arterial system delivering information as blood to the pumping organs of the body electric! Huzzah! (pass the red herring, please).

This sounds like a ComplaintPattern. Metaphor keeps people sane and capable of learning new information because it allows us to parse new data with known concepts. Sure it gets flogged by MarketingWeasels? and PointyHairedBosses but what doesn't? Careful you don't turn this into an OldFogeyRant? about the loss of HighPriest? privileges to the PowerPointAsCASE and DesignByWhitePaper? crowd.

Please explain how I StopUsingMetaphors, when my system is a RubeGoldbergMachine and my CowOrkers are a group of hopeless WarmBodies, who suffer from FearOfSuccess?

In response to top of page:

That is like the cat calling the kettle black, and it hurts the computer system's feelings to add to the toppling heap of hurtful claims.

A mountain of metaphorical discussion. Isn't a metaphor intended to provide an alternative, clearer view of particular aspects of a concept? Something which prompts the listener to see the concept in a particular light? I just wonder what can be used to replace metaphors. (Reading WhatIsAnAdvancer prompted me to write this - would WardCunningham's project have had the same success without the Advancer metaphor?) -- PeterLynch

I was struck by the mantra early on in this slightly brain-dead topic that mathematics was better then metaphor which fails to take note of the fact that mathematics is 1) itself a metaphor when applied to things not mathematics proper, sic science, software, etc. and 2) mathematics is generally not accessible, especially the more obscure mathematics, to the general run of individuals, even software engineers, so that sometimes the Metaphor is the message. -- RaySchneider

See also: MetaphorSmackdown, MetaphorDefinition.

JanuaryZeroSix

CategoryMetaphor

EditText of this page (last edited March 6, 2006) or FindPage with title or text search