I was browsing the web, searching for new ideas to help out fellow manager with some improvements he was willing to do. I went through TTD, pair programming, continuous integration, collective ownership and others. Basically, through the XP practices I knew or used. ( I have to say that every time I do study like this, I learn that I still have to learn. This was the case again.) I found out, that for a long time I was over-looking something called „metaphors“. I am quite familiar with this term and i can relate to it in many ways, but to be honest, in the agile development, I can not. So what is it?
Here are two definitions I found:
(www.extremeprogramming.org) “System Metaphor is itself a metaphor for a simple design with certain qualities. The most important quality is being able to explain the system design to new people without resorting to dumping huge documents on them. A design should have a structure that helps new people begin contributing quickly. The second quality is a design that makes naming classes and methods consistent. What you name your objects is very important for understanding the overall design of the system and code reuse as well. Being able to guess at what something might be named if it already existed and being right much of the time is a real time saver. Choose a system of names for your objects that everyone can relate to without specific, hard to earn knowledge about the system. „
(Kent Beck, Extreme Programming Explained, p. 179.) “The system metaphor is a story that everyone – customers, programmers, and managers – can tell about how the system works.” or “to give everyone a coherent story within which to work, a story that can easily be shared by the business and technical folks.”
Even though I find it interesting, I am not really sure how can this work in real life and what’s the benefit. Do you have any practical experience with it? Any examples or good advise? Do comment, please! :)
Dont you have some example of the metaphore?
As I have written in the blog, I don’t have experience with it. However, here are some links :
http://reports-archive.adm.cs.cmu.edu/anon/isri/CMU-ISRI-03-103.pdf
http://c2.com/xp/SystemMetaphor.html
http://sixrevisions.com/user-interface/5-reasons-why-metaphors-can-improve-the-user-experience/
Using metaphors to describe software or other complicated things is actually—as many other agile things—a quite old and natural technique. Just recall design patterns like Visitor, Observer, Bridge, etc. The role names and how their interaction is described tend to give an instant insight into the pattern. A Visitor visits Elements and performs whatever needed within them (while on visit, to say so). This is the Visitor design pattern. You may imagine it more vividly as a real visitor coming to your house and acting upon your things. The things may change or be exposed somehow to the outer world, but the visitor won’t remain in the house. Some architectural styles also bear metaphorical names like pipes and filters or blackboard.