A Catalog of Metaphors

[Joshua Kerievsky]

The practice of using Metaphor in software is hard and yet we've never taken steps to make it easier.  

I think a catalog of metaphors could help people, particularly metaphors that have been successfully used on software projects.  

Would folks be interested in creating such a catalog?  

Perhaps we could begin by informally sharing successful metaphor stories on this list.  

--
best regards,
jk

Industrial Logic, Inc.
Joshua Kerievsky
Founder, Extreme Programmer & Coach
http://industriallogic.com
866-540-8336 (toll free)
510-540-8336 (phone)
Berkeley, California

Learn Code Smells, Refactoring and TDD at http://industriallogic.com/elearning

[Stefan Roock]

let's try that

--
Dipl.-Inform. Stefan Roock
Senior IT-Berater, Certified Scrum Trainer

it-agile GmbH
Paul-Stritter-Weg 5, D-22297 Hamburg

Geschäftsführer: Henning Wolf, Jens Coldewey
Handelregister Hamburg, HRB: 92261
Umsatzsteuer-Identifikationsnummer: DE239483021

Fon:    +49 40 88173-300
Fax:    +49 40 88173-333
Mobile: +49 172 429 76 17
E-Mail: stefan...@it-agile.de

http://www.it-agile.de

[Eduardo Guerra]

I think it is a great idea! Let's try!

Eduardo Guerra

2010/6/10, Stefan Roock <stefan...@it-agile.de>:

--
Enviado do meu celular

[Marc Cooper]

On 10/06/10 13:02, Joshua Kerievsky wrote:
> The practice of using Metaphor in software is hard and yet we've never
> taken steps to make it easier.
>
> I think a catalog of metaphors could help people, particularly metaphors
> that have been successfully used on software projects.
>
> Would folks be interested in creating such a catalog?
>
> Perhaps we could begin by informally sharing successful metaphor stories
> on this list.

Excellent idea.

--
Best,
Marc

"Change requires small steps."

[Brandon Carlson]

I like the enthusiasm here! Has anyone other than Joshua been
successful in using metaphor and therefore be capable of helping
create the catalog?

:-)

Brandon

P.S. I haven't, but it's an interesting topic.

[Bill Wake]

I have a few things I can share, mostly put together several years ago:

http://xp123.com/xplor/xp0004/index.shtml - "The System Metaphor" (became a chapter in _XP Explored_).

http://xp123.com/g4p/0112.htm - Metaforma game - to brainstorm metaphors - many but not all of the things on there are metaphors I've seen applied to software

http://xp123.com/xplor/xp0206a/index.shtml - Metaphors for XP - at a little different level

--Bill

--
  Bill Wake   Industrial Logic, Inc.

[Ingvald Skaug]

On Thu, Jun 10, 2010 at 14:02, Joshua Kerievsky
<jos...@industriallogic.com> wrote:

> The practice of using Metaphor in software is hard and yet we've never taken
> steps to make it easier.
> I think a catalog of metaphors could help people, particularly metaphors
> that have been successfully used on software projects.
> Would folks be interested in creating such a catalog?

i would definitely be interested in _having_ such a catalog available... so yes.

maybe we should use a wiki tool or something other than just email to
brainstorm/ collect?

i recently had a great jazz keynote experience at xp2010, and wrote a
blog post about it which in essence is about jazz (or music
performance) as a metaphor.
http://skaug.no/ingvald/2010/06/kanban-agile-jazz.html
note: that post is "theoretical" - i haven't tried to use the music
performance metaphor in any context...

> Perhaps we could begin by informally sharing successful metaphor stories on
> this list.

here's a small contribution...

a co-worker and i had some success communicating about technical debt
(and later work in progress) vs throughput by using a metaphor of a
container where water comes streaming in on one side near the top, and
out at the other side near the bottom, and there is silt in the
container.

the technical debt and work in progress is the silt, and the more
there is of silt (WIP/debt) the less water (deployed work, income...)
comes out of the container.

ref context: this metaphor is quite simple, but was useful in
initiating increased understanding by non-developers in the company
about the state of the code and dev process (ref tech debt and a long
backlog).

it related to sales and management experiencing low(er) throughput,
but didn't go further (f.ex. on company vision and other business
needs). so the scope was mostly the code and dev process from backlog
to deployment.

regards,
ingvald

http://skaug.no/ingvald
http://twitter.com/ingvald

[Bill Wake]

On Mon, Jun 14, 2010 at 12:15 PM, Ingvald Skaug <ing...@gmail.com> wrote:

here's a small contribution...

a co-worker and i had some success communicating about technical debt
(and later work in progress) vs throughput by using a metaphor of a
container where water comes streaming in on one side near the top, and
out at the other side near the bottom, and there is silt in the
container.

the technical debt and work in progress is the silt, and the more
there is of silt (WIP/debt) the less water (deployed work, income...)
comes out of the container.

Very nice. I have a related example - air in a balloon. (It's a metaphor that didn't show up in the code, but was useful for talking to people about what was going on.) I helped support a call center that would dispatch technicians to do repairs. We built reports around how long it takes to do a repair. We had a phenomenon that some technicians were (apparently) taking 8 minutes to solve a day's worth of problems. This would be fine, except that they were charging for 8 hours and only fixing 8 problems a day. Some technicians had realized that they could accept a ticket, immediately mark it fixed, *then* work the job, and claim an average repair time of 1 minute. So the air in the balloon was "all the time from when the customer reports the problem until a callback verifies that they're satisfied it's fixed." You could squirt the air around inside, and decide which group to charge for which piece of air, but it all had to be included. 

--
  Bill Wake   Industrial Logic, Inc.

  Try our eLearning at http://industriallogic.com

[edm...@lia.ufc.br]

I like the Software/System Metaphor Catalog's idea, but I think it's
important first answer these: Who should use it? How it must be handled?
What would be that Catalog's central purpose? The question is concerned to
the Catalog, not to the metaphors.

Who should use that Catalog? Maybe ordinary users, business people, IT
professionals, IT students...?
How that Catalog must be handled by ordinary users?
How that Catalog must be handled by business people?
How that Catalog must be handled by IT professionals?
How that Catalog must be handled by IT students?
What would be that Catalog's central purpose?

The answers depend on the nature/kind of software metaphor we are talking
about. Are the chosen metaphors related to problem domain, solution
domain, or both?

For those metaphors related only to problem domain, the Catalog could
present tools for transforming problems: mathematicians use tools like
variable changes and function transforms (e.g Laplace, Fourier) to make
difficult problems easier to solve. It's similar to mapping concepts from
one domain into other, only to make things more manageable. Mathematicians
used to transform the problems (based on experience, catalogs, handbooks)
before starting the solution efforts. Students learn this kind of tools to
prove the correctness of their (more elegant) solutions. The public of the
proofs includes other students/professional mathematicians.

For those metaphors related only to solution domain (as in a design
pattern): "every new convenience for the user had to be paid for by the
implementation, either in the form of increased trouble during
translation, or during execution or during both" (Dijkstra, see [1]).

For those metaphors related to high-level, common understanding of the
problem/solution pair, we have to bring ideas from other fields of
knowledge such as sociology, psychology: "A boundary object is a concept
in sociology to describe information used in different ways by different
communities. They are plastic, interpreted differently across communities
but with enough immutable content to maintain integrity." (Wikipedia, see
[2]). "Beck should have boldly called it Allegory: an extended metaphor in
which a story is told to illustrate an important attribute of the subject,
or even a Parable!" (Kruchten, see [3]).

[1] http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/EWD117.html
[2] http://en.wikipedia.org/wiki/Boundary_object
[3]
http://pkruchten.wordpress.com/2009/07/21/metaphors-in-software-architecture/

Kindest regards,
@edmundoandrade

[Eduardo Guerra]

I used a metaphor in a project for the developers to understand the performance problems which can bring sending messages with an inappropriate size.

The metaphor is when you go shopping and arrive home with a lot of packages, which you need to climb stairs with.   

- If you carry very small packages, you would need to go many times, which is not efficient.

- If you carry a very big package, you would climb the stairs very slowly.

- As soon that some package arrives, you wife can begin organize it at the same time that you go to bring more packages.

- To worth compacting some packages, it need to take less time than the additional time that you would take to bring them up.

- It is important to avoid buying unnecessary things (I don't know why, but our metaphor to this was that the wife bought too many shoes).  

This metaphor helps the developers to evaluate when it is necessary to assemble remote calls in only one and when to break a response in more than one call. It also illustrates the return of unnecessary information and when the use of some compacting algorithm worth.

Thanks!

Eduardo Guerra

2010/6/10 Joshua Kerievsky <jos...@industriallogic.com>