Originally posted to XpDocumentary by TomStambaugh as part of the discussion on MetaphorsForNontechnicalAudience:

The metaphor needs to be apt, correct, and understandable -- whatever the audience. I personally find music metaphors more successful than any other. It seems to me that the "classical" school of software development begins with a commission (requirements), and is followed by a composer writing a score (design). This score is then expanded into parts, and ultimately about 50 separate, but related, pieces of sheet music get distributed (implementation). Finally, the orchestra plays the parts -- and this is the first time the music is actually HEARD. Late changes are VERY expensive. After lots of practice (debugging), the new music is performed for paying customers (deployment). 

I play jazz. The "extreme" school of software development begins with a music lover who expresses a request for some blues ("story"). The band ("programmers) lays down a line and watches to see whether the music lover is tapping his feet or not ("unit test"). The musicians have a common vocabulary, have deep and shared experience with riffs that do and don't work, and the resulting music emerges as they elaborate the basic theme. New themes and ideas pop up all the time, and if the musicians are good enough, the whole house is rocking and shaking by the end of the set. The music happens early; it emerges and evolves in response to the customer's desires.

In my view, this music metaphor is perhaps even more amenable to inclusion in a documentary, it lends itself well towards elaboration as the material gets more technical, and the differences between "classical" and "jazz" music are apparent even to a non-technical audience. At a more subtle level, this metaphor also captures some of the fluidity of the distinction. After all, "Rhapsody in Blue" is pretty good Jazz, and pretty good Classical. Nearly every good or great Jazz musician is classicly trained -- and not the inverse. Good improvisatory music is rooted in years of humble pragmatic discipline and practice. And so on and so forth.

''Amen.''

----

That would add a whole new dimension to the XpDocumentary, as well. You could have some jazz playing in the background when discussing technical details, maybe contrasting shots between a jazz duet and a pair of programmers. 

''I need to add, here, that I love classical music -- especially when experienced live, in the presence of an accomplished orchestra. The two genres are NOT competitive, it is NOT a ZeroSumGame?, and each contributes enormous insight to the other. I feel that a similar situation exists between classical and Xp methodologies. There is BAD classical music, there is BAD jazz, there is BAD classical software, and there is BAD Xp software. These realities don't negate the reality of the two genres, and I'd like to see us celebrate and learn from their differences, even as each of us pursues the "music" of our own taste. -- TomStambaugh''

True, quality is so ... qualitative with music. However, if you have two pieces of music with the same quality (enjoyment factor), which one is more expensive to develop? If quality is held constant, the metaphor still holds up. 

----

[Quoted from the XP list]

I think the problem might be that "but where does design come from in XP" is a question analogous to asking "but where does the *art* come from in your stuff" to a concert violonist.

She might tell you which pieces are good for beginners and which you should try only later, she might tell you about the music notation - possibly with a mention that you don't need to know about hemisemiquavers right away - and which performers she thinks are at the top of her profession, and why X who does one thing is very good but Y who does an entirely different thing is very good too.	

She'd tell you these, and a thousand other things, but if you kept on asking "fine, but how do I make *art* with all this", she'd just shrug and go back to her own practicing.

[...]

If your customer is paying you for code that works when it's delivered and keeps working as it's being maintained - then pretty diagrams and documentation are pointless not because they change but because they have *no bearing* on whether the code works or will keep working.

To go back to [the] analogy - it is as if there was a philosophy of music asserting that first you write a libretto, and then you write nice score sheets with notes and tempi and pianissimos and so on and *that* is what ensures that the music is beautiful. XP says not to worry about the scoresheets and libretto - first you hum the music aloud, then you get a few guys to play it, then if it's good you record it. All the rest is, well... merely instrumental.

----
See SoftwareDevelopmentComparedToJazz, NewAnalogiesForSoftware, JazzProgrammer, DevelopmentTeamModels, AnalogiesFromMusic, MetaphorsForNontechnicalAudience, FreeSoftwareMusicAnalogy