Gunjan Doshi

In the first edition of Extreme Programming explained, Kent Beck had included the practice of Metaphor. It was supposed to help teams evolve a common architecture vision & vocabulary. I tried hard to apply it, but never got it right. I then came across the practice of Ubiquotous language from Domain Driven Design book by Eric Evans. I now use the practice of Ubiquotous language regularly.

In the second edition of Extreme Programming Explained, Kent dropped Metaphor as a practice. I was interested to know his reasoning behind it. Recently, when asked about this, Kent Beck replied on the extremeprogramming yahoogroup:

<KentBeck>
I do think metaphors are important. The language you use shapes the way you think which shapes how you program. Sharing metaphors does help a team communicate with each other and their users. However Metaphor is not an XP practice, any more than typing is a practice. Less, actually, since typing is a consciously learned skill. You learn metaphors from the moment someone points to the picture in the board book and tries to convince you it’s an airplane, maybe before. You know it isn’t an airplane. You know they know it isn’t an airplane. You learn that you use one thing to represent another.

I don’t think anyone can think abstractly without using metaphor. It can be very valuable to be aware of the metaphors you are using, sometimes even choosing them consciously. It is redundant to include metaphor as a practice, since you can’t help having metaphors. That is why I removed it from the list of practices. It is still worth thinking and talking about.
</KentBeck>

So, Metaphor is no longer stated explicitly as a practice; it is a good design aid like UML that if applied correctly can help create a common vision.

Tags: No Comments