In a seminar on objects jointly presented with SteveCook in 1990 I suggested that we should look to music, perhaps especially Jazz, as a much more fruitful analogy for what team development using EvolutionaryDelivery should feel like.  I wondered then and now if it was an accident that both Steve and AlanKay were excellent Jazz musicians.

By the way I play the piano a bit but I can't improvise to save my life so this suggestions may also be AnalogyAsWishFulfilment.  It wouldn't be the first time and it's sure important to recognise the dangers of this.  Look at the damage the highly wishful term ''Software Architect'' has done for so many years in the face of typically messy, tough, incremental real world design decisions.  And how often it's led to flat denial of the few provably useful programming practices that we've had available.

The idea wasn't taken up very widely, needless to say.  But the last few weeks have given me a couple of grains of comfort.

In the first conference session I ever attend on XP (at OtNinetyNine in Oxford on 29th March 1999) DavidHarvey and PaulDyson claim that one of XP's great strengths is its emphasis on ''direct contact with the medium - unmediated and unselfconscious''.  See IsXpAnUnselfconsciousProcess for more details.

An animated discussion follows of how appropriate and realistic this is for software and within minutes an XP sympathiser reaches for an analogy ... of the great jazz musician Charlie Parker and those that seek to emulate him.  Tons of discipline, practice and skill is of course needed but direct interaction with the medium is of the essence.

When I return from Oxford I find that the revised edition of PeopleWare has arrived from Amazon.  There's just one '''STARTLING CONFESSION FROM THE AUTHORS''' - on pages 184-185:

''Throughout this book we have used and discussed the sports team as a metaphor for the well-jelled technical work group; we are now obliged to emphasize here our growing disenchantment with this metaphor ... most troubling is what this metaphor implies about competition  ... football teams ... promote a good deal of internal competition ... we have seen individual team members have a great night while their team was losing badly ... by contrast a choir or glee club makes an almost perfect linkage between the success of failure of the individual and that of the group ... you'll never have people congratulate you on singing your part perfectly while the choir as a whole sings off-key ... so belatedly we need to tell you that the musical ensemble would have been a happier mataphor ...''

The attention of De Marco and Lister to important detail in the parallel domain and their recognition of the limitations of an earlier analogy as a result are I believe a great example for other authors on software to follow.

I continue to feel that none of us have remotely exhausted the usefulness of group/individual improvisation/performance/composition of music as a rich source of analogy for development, especially in the context of very encouraging improvements in process such as ExtremeProgramming. 

--RichardDrake

----

''"by contrast a choir or glee club makes an almost perfect linkage between the success of failure of the individual and that of the group"''

The thing that makes me nervous about this example, is that choirs,
glee clubs, and orchestral string sections require, more or less,
absolute conformity to a central authority such as a conductor. It's
true that being correct but out of step doesn't help, but this is also
true of the parade ground. At least for me, this wouldn't be my favourite development environment. 

Other sections of the orchestra and other types of band require a fine
balance between individuality and cooperation which, I guess, is what
the authors were getting at. But when the band is not playing right,
the only thing you can do is play your part as best you can and hope
for the best -- which brings us back to sports teams -- and I've played in some dreadful bands.

Actually, I think there are other parallels between software and music
which are interesting. In particular, the development of a skill that
involves amazing attention to detail, the knowledge of when and how to
fake things to get the right result, and awareness that technique
alone is not enough. --SteveFreeman

''right on, brother (sorry, can't help the pentecostal/gospel analogies coming through at this point, they've been lurking there for too long now)''

Fine; if you don't like the analogy of a choir, consider a barbershop quartet.  
There's no conductor, it's self-organizing, and depends on a ''lot'' of fine,
continuous feedback.  And it has the same strengths as the choir analogy.

And there's one thing about the choral analogy that's crucial: an important
skill in choral music is ''blending'', fitting in so that you contribute to
the overall sound of the choir rather than standing out.  Many voices that 
are fantastic for solo or duet singing stand out like a sore thumb in a choir,
and such singers need to learn a very different kind of voice control to be
good choral singers.  I'm a rather poor solo singer, but I've been told by two 
different choir directors that I'm a very good choral singer primarily because
of my skill at blending.  Try as you might, you can't hear my voice in a choir,
but when I stop singing, you can hear the difference (if it's a smallish
choir, of course).  That's the goal.  --GlennVanderburg

''Great stuff.  It's interesting to realise again AlanKay's interest not just in Jazz ... but in building pipe organs.  His only professional membership has to do with this!  There really is something important in this sense of beauty and blending for software.''

''DonaldKnuth owns a large pipe organ, professionally built. A good use of the royalties from TheArtOfComputerProgramming. -- RobertField''
----

Stravinsky, in The Poetics of Music:  You cannot create against a yielding medium.

Computers are certainly unyielding, leading to great sonatas of software... ''seriously, where?''

----
I think you can draw an analogy between classical music notation and software modelling:
	* Key signatures (and other pitch-related markings) => static structure (class diagrams)
	* Time signatures (rests and other time-related marks) => dynamic modelling (e.g. statecharts, interaction diagrams and activity diagrams)

You can think of both concepts as separate dimensions that can be independently manipulated. For example transposing a song into a different key leaves the rhythm unchanged, whilst changing the tempo, or fiddling with the lengths of 
individual notes leaves the pitch unchanged. In Kruchten's 4+1 model of software, scenarios form a link between each separate view. In traditional music
notation, the notes play this role (since describing notes involves both pitch and duration.)

Just a thought...

--some guy

The statespace of '''all musical pieces of a special style''' can be seen as  (an appropriately to be defined) subset of all "path sets" over a fixed 3D landscape. See DataMusicVoxelApplet. A simple path can be identified as a singleton "path set", a monophonic piece of music. A sample of a music piece with 3 voices is a "path set" with three paths of equal length.
For a more formal definition we can see music pieces as morphisms of special finitely generated categories (in the sense of Mathematical Category Theory).
These morphism are "induced" by an appropriately to be defined Functor.
The input category of this functor is the statespace of a (human or nothuman) composer. The ''morphisms of the input category are state trajectories'' of the musical mind, being related with the induced music trajectories by the mentioned Functor.
In analogy to a powerset you can define the power category of a base category.
The ''morphisms of the base category are monophonic music pieces'', the ''morphism of the power category are polyphonic music pieces''. 
This is a simplification. Actually we need a family of such functors that are indexed by objects of the power category. If we do this we get the concept of '''categories operating on categories'''. This in turn is a natural generalization of finite automatons. (Simply replace the morphisms of the traditional free input monoid, generated over a finite alphabet, by the paths of a finite graph). -- FridemarPache

This makes no sense. In order to perform these operations upon this sort of statespace, we would have to first quantify those things which make Style, wouldn't we? These mathematics are unrelated to mathematics; they are metaphors, which is fine; but one wonders if the composition of metaphors is allowable by "the mathematics of wiki posting." --TanyaEss

----

I play bass.  I also played in a band that strove to perform "rehearsed sounding improv" (there has to be a better name for this type of thing- transparent improv?)  Here are some things I've observed that I think are key:

	* when improvising, the most proficient player should =follow= the less proficient players.  this creates the opportunity for the more advanced musician to:
	* create a context which makes the sounds played by the other musicians "make sense".  that is, if i'm attentive enough, i can have two people playing instruments (each only paying attention to their own parts) and provide a "bridge" between them.

Does this make sense?  I wanted to get this idea out there, however, I'm not feeling very articulate at the moment, so if someone understands what I'm driving at here and would like to add to this or make it clearer, i'd appreciate it.

-BenSharp

----
We all can play music. Few can write it. Most of my favourite music is the complete creation of one or two people. The musical component of it is the concept of one person. If the application is the symphony, the analogy to programming would have us all writing a bar each. Maybe that is why so many applications are dysfunctional. -- PeterLynch
*''I agree with this analogy completely.''

----
See also JazzProgrammer, ChoralMusic, WikiMusicLinks