See also: AttributeBasedArchitecturalStyles, ProblemFrame, ProvenSystemMetaphors, WomenFireAndDangerousThings, (the wonderful) MetaphorsWeLiveBy, UbiquitousLanguage, AnalogyBreakdownAntiPattern, CategoryMetaphor
You mean Paris, Kentucky, right? :) Or perhaps a polar route during a cold winter...
Surely the problem, at its core, is rather like something your team already knows how to experience. Uh, this may take some brainstorming... And, you then have to code up a SpikeSolution to check whether the metaphor actually holds water for your problem (pardon the metaphor). -- AlistairCockburn
Chrysler is a manufacturing company; we make cars. Using a manufacturing metaphor to define the project was an important first step in getting the team (and management) on a level playing field. The concepts of lines, parts, bins, jobs, and stations are metaphors understood throughout the company. The team had the benefit of a very rich DomainModel developed by members of the team in the project's first iteration. It gave the members of the project an edge in understanding an extremely complex domain.
"The system is a bakery" jibes better than "The system interprets text as commands and executes them against builders that produce resultant objects and attach assorted decorators, sorting them via pipes and filters to the correct bins; the user can than browse and eat them as needed." -- RodneyRyan?
Hmmm, I think we've lost sight of what a Metaphor really is. I believe a SystemModel? is inescapable, but SystemMetaphor is not. Fundamentally all players in a system development will, as a bare minimum, be working with a MentalModel of the system, but to describe the system by analogy (the SystemMetaphor) is extra work that may or not be carried out (or required) (or useful) -- PaulGallagher?
[Q: is part of the role of SystemMetaphor to ensure that all the players have a simple, shared vocabulary for synchronizing their MentalModels? LaurentBossavit's comments near the bottom seem to suggest yes. -- WikiWikiWeb]
For my money the answer lies in an article written by PeterNaur in about 1986, called "ProgrammingAsTheoryBuilding". I read it in the book Computing as a Human Activity, a collection of Naur's writings, probably just around his retiring or something.
In it, he argues vociferously against "methods" on the grounds that you can't possibly prescribe solutions to intellectual problems. But that's not the relevant bit.
The relevant bit is where he says that a program manifests a theory that the programmer has constructed about the problem and the solution and how they match. The quality of the design has a lot to do with the quality of the match.
But even more relevant is where he says that the maintenance or next programmer is faced with creating a theory about the problem and the *previous* programmer's solution, and the quality of his addition to the code base has a lot to do with how closely *his* theory matches the previous programmer's theory.
Suddenly metaphors become relevant. I visited ChryslerComprehensiveCompensation, and saw that the people there were operating to approximately the same theory. The metaphor, with all of its associations flying around people's brains, holds together a "theory" about the system that is easy to transfer to another person's brain. Say a few more sentences about which aspects of the selected metaphor are relevant to the system under design, and the listener suddenly has a huge theory to work from in examining, and adding to, the system.
The difference between AntsAndBees is suitable. You might find that the bees metaphor does not hold up well as a theory for the solution, the design of the system, because you want more trails being laid than missionaries returning with maps. That simple distinction - assuming its relevant - holds together a lot of code text and informs a lot of programmers quickly over a long period of time.
And that's why a metaphor for the system is valuable (IMO). -- AlistairCockburn
Another reason a shared story, or metaphor, could be useful: Agreeing on common language to describe a problem facilitates community knowledge over individual knowledge. -- DaveHoover And a community theory of a business system (based on that collective learning/knowledge) is likely closer to the mark than an individual's theory. And if it requires a reduction or simplification of the lexicon to achieve that consensus story/theory, all the better for the eventual system. Caveats: Don't rule out an innovative view of the system, don't dumb-down to simplify... dumb-up :) -- ChristopherGaltenberg
I think we make a mistake when we think that SystemMetaphor is some exotic thing. After all, we use the object metaphor all the time: this set of bits is an object. Object orientation is metaphorical thinking.
Stack, desktop, window, JINI lease, even Account. That set of bits in RAM isn't really an account, but it is useful to think that it is. And, if it ever becomes more useful to think of it as a reservoir served by pumps, you can go to that.
Personally, I think that 'RenameClass' is the most powerful refactoring. You have to be very careful with it.
For my money, the relevant section in ObjectOrientedSoftwareConstruction is essentially content-free. Bertrand points out that metaphors are a powerful tool in the exposition of difficult ideas (without giving specific examples) then asserts that they are dangerous, giving as sole evidence for the assertion a passage by BenjaminFranklin quoted out of context and ridiculed by Gaston Bachelard. The only substantive argument given is that we must be wary of the "proof by analogy", as given above.
The "proof by analogy" is itself a StrawMan. If we say that a Kohonen Net is like an anthill, or that SETI is like a beehive (see AntsAndBees), I doubt that we will ever be tempted to say that a Kohonen Net has mandibles, or that a SETI cluster has yellow and black stripes. The actual use of metaphor is more as follows:
There is precisely as much "danger" of drawing "false" insights from the use of a high-level metaphor as there is of drawing "false" insights from a low-level metaphor.
It seems to me that what SystemMetaphor says is this:
If you don't suggest a metaphor, then their metaphors will probably share fewer features, especially at first. That forces everyone to develop their own metaphors by trial and error, then go through many of the same trials and errors all over again to communicate - and with no proof that all the tsuris will result in better metaphors than would result from providing a common metaphor to begin with.
PaulGallagher? and TimVoght, is there a reason to assume that the audience's metaphors will be "purer" or "more accurate" if the SystemMetaphor is not provided? -- RonPhillips
Why would it be early?
You could consider the SystemMetaphor as a way of structuring the ConceptualModel. All systems should have a ConceptualModel, describing the concepts visible to users and the associations between them. It is easy to end up with a very complex ConceptualModel though. Think about the concepts Windows users are expected to get their heads around! A SystemMetaphor provides an overall 'theme' to the model. Apple did this with their original DesktopMetaphor?. -- MikeHowells
Design is a natural process. We are all quite capable of building the ConceptualModel in our heads. And given a communication language which is appropriate we are capable of transferring that ConceptualModel to the next person.
We do not have that language.
What we need is a set of SystemMetaphor instances which constitute the basic building blocks of a system. These could constitute an intermediate language, capable of being implemented at least as an ActiveModel?.
The design task is capturing and refining the ConceptualModel in an appropriate time frame. This requires good communication. In a randomly chosen set of humans, each of the people with the concept in the head would use a different semantic base to explain it. So, unless the listener is very experienced, there can be a blurring of the meaning at the point of transfer.
What I believe we need is a clear semantic base. A base which is not in the domain of computing, but a base which is in the domain of spoken language. How you go about finding that semantic base is a challenge. I would place it in a category as important to humanity as algebra.
Because computing is pervasive, this semantic base could be quite sophisticated. It is likely that it would be taught in schools, possibly at the same level as early algebra.
It could go something like this -
The base elements of the semantic base are the two things which we intuit quite well: processes and data.
A semantic base for processes is -
One thing it establishes is a concept of flow: stuff goes in on the RHS and comes out on the LHS. Like algebra.
And given that premise that there is a useful semantic model in which all data can be described sufficiently to specify enough intention to allow the use of intelligent defaults to provide useful, usable immediate functionality, there is a finite set of semantically clear processes, which, if considered in the light of that model, provide all the functionality which is provided in the current generation of databases. And more.
Data is a set of instances which can be conceived as the combination of the Entity in which it exists, the Attributes required, and the identifier of the instance.
Given this view of data, a set of processes can be conceived to allow communication about the access of data.
In the course on XP I took, metaphors seemed to be the most unconceivable concept. Even here, agreement is only reached on the first two lines of this page, the rest being a presentation of very different ideas on what a system metaphor actually is.
I believe one main problem is, that we are lacking a common, shared metaphor for metaphors.
An important point may be, that metaphors cannot possibly be constant throughout a project. They will change very quickly (minutes) in the beginning, but may also stay basically unchanged for several iterations. There will never be one metaphor, because a metaphor is a shared story, every team member will have his own version, lacking some details. So the metaphors will evolve, and eventually become an unmetaphoric entity (an 'icon', i.e., on a windows desktop, was a metaphor once; now everyone has a sure grasp of the concept behind it, and one can name the actual object 'icon').
A big problem might be the usage of metaphors as system architecture. It might work very well for initial development. But I believe that it can be very difficult to continue someone else's project, because the complex, evolved metaphors will be a very hard thing to pass on. -- RonaldToegl
That would be the NativeMetaphor
Importantly, the "teaching function" of a metaphor extends beyond mere knowledge transfer to ongoing knowledge discovery. That is, every metaphor is rich with implications that we can continually explore to guide our immersion in an area of unfamiliarity. For example, if we say that a (future) document management system will be like a library then we can start to discover the scope and details of the document management system in considerable detail by following the implications of what it means to be a library.
This helps with early brainstorming, group communication, and ongoing exploration as the project unfolds. An important consequence of this is that the metaphor helps maintain conceptual cohesion - providing an overall filter on the things that go into the design. Thus, our document management system would be constrained by the limits of the library metaphor. Assuming the metaphor is a good one, this limiting will stop us straying off the cohesive conceptual path. Of course, a poor metaphor will lead to poor guidance.
In my experience, the simpler the metaphor the less likely we are to be tripped up by it. Experience has also taught me that although it is helpful for all the team to share the same original understanding of the underlying metaphor, this is highly unlikely, but is rarely problematic since what is normally required up-front is only sufficient overlap to enable mutual exploration. For example: "No, I don't mean the library will only have one copy of each book; this is a library with infinite copies of every book ...". -- AnthonyLauder
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006