Nill, Christian
2005-07-29 18:56:40 UTC
Hi Kent, hello Everyone,
I only recently bought the 2nd edition of XP Explained and what I have
noticed first from all the changes and refinements is the virtually
total abolition of the metaphor. Only once, on page 75 sketching out the
role of interaction designers in XP teams, you wrote: "Interaction
designers on an XP team choose overall metaphors for the system, (...)".
I am a Masters student currently doing an internship with SAP Labs in
Palo Alto and writing on my Masters thesis which is concerned with
metaphors in software development.
I've heard and read quite a few opinions on why system metaphor as a
practice failed. For one it often seemed difficult to find a common
source on which to found the metaphor, the bigger a team the more
difficult it became. Additionally, especially experts from the
application domain are not always happy to talk in terms of some strange
metaphor about what the system should accomplish, so it couldn't be used
for communication with the customer (unless the customer didn't know at
all what he wanted). Also concerns over metaphors becoming to powerful
and fully determining the systems capabilities were uttered. And so
on...
I still think that metaphors can be very meaningful in software
development in general and also in XP. However rather than aligning the
whole system around one or two all-embracing metaphors, consider a more
fundamental idea like the Tools And Materials Metaphors (only sketched
out rudimentarily at
http://www.c2.com/cgi/wiki?ToolsAndMaterialsMetaphor). Quite a lot of
pretty basic metaphors that make some sense to everyone regardless of
the background are being used to structure application domains, rather
than explaining them in their entirety.
Tools, Materials, Automatons, Containers are all more or less
visualizable and explained in a rather short statement. E.g. Materials
represent all sorts of business entities like accounts, orders, forms,
and so on. In general, a user can work on Materials by using Tools.
Automatons don't require user interaction and are good for repetitive
tasks. Containers hold Materials. These are just a few Metaphors that
are being introduced in Heinz Zuellighoven's "Object-Oriented
Construction Handbook: Developing Application-oriented software with the
tools and materials approach". Also his collection is not necessarily
complete - depending on the application domain one might add Messages /
Events, Workflows, etc.
Besides proposing a rather stringent set of metaphors for structuring
application domains and thereby facilitating communication especially
with non-technical team members the book brings forward something else.
A collection of design patterns provides a rough mapping of design
metaphors into software architecture. In that way the original idea of
the system metaphor to serve as a kind of architectural blueprint is
being preserved. Without additional artifacts (except maybe for the
pattern documentation alongside the more established design patterns)
structure could be given to the software application.
And - most importantly - in such a setting the customer's wishes would
find their way into the code in a relatively straightforward manner.
Should it turn out that new wishes can not be expressed by existing
metaphorical constructs, you're always free to create a new one or even
apply it completely outside if nothing else helps.
Admittedly this description of using a multitude of more or less
concluded, but intertwined metaphors is a bit on the vague side, but I
still would love to hear your stance on it. Is btw someone familiar with
the "Tools and Materials approach"?
Best regards,
Christian Nill
------------------------ Yahoo! Groups Sponsor --------------------~-->
<font face=arial size=-1><a href="http://us.ard.yahoo.com/SIG=12h4slgf7/M=362329.6886308.7839368.1510227/D=groups/S=1705007207:TM/Y=YAHOO/EXP=1122670833/A=2894321/R=0/SIG=11dvsfulr/*http://youthnoise.com/page.php?page_id=1992
">Fair play? Video games influencing politics. Click and talk back!</a>.</font>
--------------------------------------------------------------------~->
I only recently bought the 2nd edition of XP Explained and what I have
noticed first from all the changes and refinements is the virtually
total abolition of the metaphor. Only once, on page 75 sketching out the
role of interaction designers in XP teams, you wrote: "Interaction
designers on an XP team choose overall metaphors for the system, (...)".
I am a Masters student currently doing an internship with SAP Labs in
Palo Alto and writing on my Masters thesis which is concerned with
metaphors in software development.
I've heard and read quite a few opinions on why system metaphor as a
practice failed. For one it often seemed difficult to find a common
source on which to found the metaphor, the bigger a team the more
difficult it became. Additionally, especially experts from the
application domain are not always happy to talk in terms of some strange
metaphor about what the system should accomplish, so it couldn't be used
for communication with the customer (unless the customer didn't know at
all what he wanted). Also concerns over metaphors becoming to powerful
and fully determining the systems capabilities were uttered. And so
on...
I still think that metaphors can be very meaningful in software
development in general and also in XP. However rather than aligning the
whole system around one or two all-embracing metaphors, consider a more
fundamental idea like the Tools And Materials Metaphors (only sketched
out rudimentarily at
http://www.c2.com/cgi/wiki?ToolsAndMaterialsMetaphor). Quite a lot of
pretty basic metaphors that make some sense to everyone regardless of
the background are being used to structure application domains, rather
than explaining them in their entirety.
Tools, Materials, Automatons, Containers are all more or less
visualizable and explained in a rather short statement. E.g. Materials
represent all sorts of business entities like accounts, orders, forms,
and so on. In general, a user can work on Materials by using Tools.
Automatons don't require user interaction and are good for repetitive
tasks. Containers hold Materials. These are just a few Metaphors that
are being introduced in Heinz Zuellighoven's "Object-Oriented
Construction Handbook: Developing Application-oriented software with the
tools and materials approach". Also his collection is not necessarily
complete - depending on the application domain one might add Messages /
Events, Workflows, etc.
Besides proposing a rather stringent set of metaphors for structuring
application domains and thereby facilitating communication especially
with non-technical team members the book brings forward something else.
A collection of design patterns provides a rough mapping of design
metaphors into software architecture. In that way the original idea of
the system metaphor to serve as a kind of architectural blueprint is
being preserved. Without additional artifacts (except maybe for the
pattern documentation alongside the more established design patterns)
structure could be given to the software application.
And - most importantly - in such a setting the customer's wishes would
find their way into the code in a relatively straightforward manner.
Should it turn out that new wishes can not be expressed by existing
metaphorical constructs, you're always free to create a new one or even
apply it completely outside if nothing else helps.
Admittedly this description of using a multitude of more or less
concluded, but intertwined metaphors is a bit on the vague side, but I
still would love to hear your stance on it. Is btw someone familiar with
the "Tools and Materials approach"?
Best regards,
Christian Nill
------------------------ Yahoo! Groups Sponsor --------------------~-->
<font face=arial size=-1><a href="http://us.ard.yahoo.com/SIG=12h4slgf7/M=362329.6886308.7839368.1510227/D=groups/S=1705007207:TM/Y=YAHOO/EXP=1122670833/A=2894321/R=0/SIG=11dvsfulr/*http://youthnoise.com/page.php?page_id=1992
">Fair play? Video games influencing politics. Click and talk back!</a>.</font>
--------------------------------------------------------------------~->