Using metaphore in the application domain
Tuesday I caught the presentation “System metaphore revisted” by Joshua Kerievsky and Brian Foote. The presentation was interesting, but left me with some mixed feelings.
Firstly let me say that I was not previously familiar with XP’s metaphore. I will not attempt an exmplanation, I may get some important points wrong, and in any case there is already existing liturature on the subject.
Their presentation brought up various example of metaphores applied to entire systems, and the continual reflection that goes into finding an appropriate metaphore. A good metaphore can facilitate understanding of the system and generate insight into new ideas. This is inded a powerful tool.
Metaphore is already present in much of our common, every-day software landscape, and helps express the behaviour of many of its components. Some plaform examples include pipes and streams, some system examples include folders and files and desktops. These metaphores provoke clues as to what is being described and the kind of behaviour that can be expected.
A few questions in the room were raised about how the metaphore relates to the use of the ubiquitous domain language advocated in DDD. The answers did not resolve the uneasyiness that I felt at the idea of mixing metaphore in the domain language or in replacing the domain language with a metaphore.
The idea of metaphore appears to work well in a context where you are developing YOUR application and you are your own client. I really dont see the interest in using a metaphore to describe an application in a context where the domain is already well defined and provides a wealth of terms to describ it. Better yet, the domain language does not need translating between developers and users. It seems wastfull and dangerous to add potential confusion to an already difficult process.
A side disscussion after the presentation with Rebecca Wirfs-Brock and Michel Feathers (I hate plugging names, but the insight is not my own), lead to the suggestion that the value of the metaphore arises from providing a parallel for a behavior we can relate to. A given metaphore provides an insight for a kind of problem. Perphaps we need a catalog of metaphores that can help to simplify the expression of common subsystems.
So in order to simplify the expressing of something with assembly line charactersistics the assembly line metaphore is appropriate. Certainly a small body of metaphores could easily cover a good number of underlying application behaviors. These start to tend towards patterns and frameworks: “if faced with such and such a situation, apply this kind of solution”.
A cautionary note is due here: it is impossible to expect a catalog of metaphores to meet high-level application needs, if this was possible a handfull of applications would have dominated the world’s business world. Alas things are not that simple.
I think these guys have done some cool stuff with the idea of the metaphore, and I can see an interest in exploring it when the domain is mine to choose. I’m relatively certain that the overhead of model to domain translation required to communicate with clients is unnecessay and unjustifiable on a project with a pre-defined domain language.
