Software Development Compared To Jazz
Software Development Compared To JazzAlistairCockburn makes some very thought provoking points in his paper on SoftwareDevelopmentAsaCooperativeGame (found in more detail at http://members.aol.com/humansandt/papers/asgame/asgame.htm)
If engaging your readers in contemplation is any sign of success, then Alistair is surely on a winning path.
He states “Of all the comparison partners for software development that I have seen, rock climbing has emerged as the best.” Elsewhere he alludes to the similarities between SoftwareDevelopment and JazzMusic; a metaphor that this article thinks best exemplifies a cooperative, finite, goal-seeking, group game.
The inspiration for the following comparisons between Jazz and SoftwareDevelopment come from the words and phrases used by Alistair to compare rock climbing (where he refers to AdaptiveSoftwareDevelopment by JimHighsmith as having more detail).
Technical
Musicians must have technical proficiency with their instrument for performance. A novice may only start with pentatonic-based Blues progressions before moving into more complex modes and chord changes. If the group is not playing an original composition, one or many members of the group must have proficiency with composing music. This is analogous to programmers creating a structured design before they start development.
From my perspective, the pinnacle of enjoyment in rock climbing involves getting in touch with the chaos of nature and climbing real rocks. Not in designing and developing their own rocks :-). The pinnacle thrill for jazz musicians is to perform and have appreciated a tune they’ve composed. To be fair, there are some rock climbers who demonstrate technical skill in designing and creating artificial, simulated rock surfaces.
Goal-Oriented
Just as rock climbers seek to reach the top of a rock, Jazz performers seek to successfully reach the end of a song as a goal. Jazz composers seek to deliver a framework for performers, or a product of enjoyment for listeners.
While the team communication and moves executed by rock-climbers may be similar to Software Development, the goal of the climb is not to deliver a product for others to enjoy, as it is when composing or performing Jazz.
Training
Jazz musicians and composers continually train and practice to improve their skills. While there is little debate over what the definition and training of traditional Jazz should be, the contemporary Jazz schools go in myriad directions.
Tools
The beauty of Jazz is that it can be expressed and performed with the most fundamental of tools, such as the human voice, or the most complex, such as computers, synthesizers, and drum machines. Saxophone, Trumpet, Piano, Guitar, and Bass Guitar are among the most common tools.
It is in within the most contemporary vein of Jazz that utilizes computers to compose and perform music that I draw many parallels with Jazz and Software Development.
As the level of production increases, so to does the demand for tools. Where SW Developers need version control systems and PC-Lint to grow, Jazz musicians need tuners, sheet music, microphones, PA systems, and mixing boards.
Individual-Team
Jazz can be composed or performed by an individual or a team (group). Jazz groups frequently perform in trios, quartets, or even big bands.
Software Developers seem to intrinsically enjoy working alone, but when a pair programming methodology is adopted I find that a jazz-like group synergy is created in the programming environment.
Planned-Improvised
Improvisation is where Jazz differs from most other musical song forms. A basic structure is first planned. The most fundamental song structure is AABA which represents that an ‘A’ section consisting of perhaps 12 bars is repeated twice before a contrasting ‘B’ section, or ‘bridge’, is played. One more ‘A’ section is then played before repeating the whole structure.
A common ‘plan’ is to play a song’s melody through the first pass of the structure, improvise over subsequent passes, and then end with a final playing of the melody (‘head’). The order of soloists and how many bars they will solo may or may not be planned. A measure of a groups technical ability is how well they are able to communicate pieces of information during a performance so that if a player is playing particularly well, the group adapts and allows them to continue their improvisation.
Groups may plan more complicated pieces that involve multiple time signatures, more elaborate chord progressions, or complicated song structures.
Challenging-Fun
Of all the musical forms of expression why choose Jazz? Perhaps musicians and composers are attracted by both the left brain demands of chord structures and scales and the right-brained escape to the world of improvisation and creative self-expression. Regardless of their reasons, challenge and self-entertainment are obvious ingredients to their attraction.
Programmers are often attracted to Software for these same reasons.
Technical Pass/Fail
Jazz and Software are often accepted based on a variety of subjective and objective criteria. The seemingly free form, aesthetic surface of graphical user interfaces and guitar solos are largely dependent upon the precise technical execution of a framework of event handlers and rhythm sections.
Having this objective framework in place allows musicians and programmers to push the limits of their craft through experimentation and grow into new idioms and ideas. The best of these explored regions are ultimately incorporated into the framework once a technical pass/fail assertion can be made and new ideas are then invented on top of the previous.
Dangerous
Jazz is probably no more dangerous than software development and certainly less dangerous than rock climbing.
Danger can be defined as “exposure or vulnerability to harm or risk”. Although developing software doesn’t put a programmer in harms way to the extent rock climbing does, it does carry similar amounts of risk found in Jazz.
There’s a group risk that the project or performance will fail. There’s an individual risk that the programmer or musician will not yet have the technical skills to successfully execute.
In both crafts, it’s not uncommon for individuals to pursue some sort of ‘fight or flight’ adrenal response in what they do to put themselves into some degree of danger.
Conclusion
There’s probably no point in debating which activity makes the best comparison partner for software development. The reason for any metaphor is simply to help communicate a concept, which rock climbing certainly does. My major points of difference are that Jazz is actually a goal-oriented game that has final deliverables, analogous to software products, that are critically received. Rock-climbing is a game that satiates personal goals, whereas Jazz and software development are games that must consider the audience.
The point AlistairCockburn has so well articulated is that Software is a cooperative game and when approached as one (such as in rock climbing or a Jazz jam) the whole experience becomes an enjoyable and repeatable process. Isn’t that the ultimate goal of any methodology?
I find the following quote particularly useful:
“The game is to deliver the software. Any other activity is secondary. A model, or, indeed, any communication, is sufficient, as soon as it permits the next person to make their next move. The work products of the team, therefore, should be measured for their sufficiency with respect to communicating to their target group”
Comments:
Good analogy. However, I wonder if the music metaphor is lost on non-musician types. Anyone? I once brought up on comp.object how to me composing was very analogous to writing software, and there was at least one person who basically called me idiot for making such a comparison... never mind that I am a composer and software engineer and he was just a software engineer. Specifically, this person was repelled by the fact that I stated almost all composers iteratively develop their work, oftentimes revising ("refactoring?") significantly along the way. A long piece does not just fall from the sky and land on the paper whole, although that is how he envisioned all great music must have come to be. To me, the process of composing is much like the process of writing software, although the tools and techniques and talents are quite different. --JohnPerkins
It's very enchanting and romantic for many to believe that music is spontaneously created. As a professional, I suppose it's in our best interest to not disillusion them, but at the same time be forthcoming and honest to those who are curious.
Without a doubt, most music compositions are created iteratively. There's a saying in Nashville amongst songwriters that "songs aren't written, they're re-written."
Is this metaphor lost on non-musician types? Perhaps, but I believe this process is fundamental to all creative processes. In my studies, I've observed iterative development patterns in use by screen writers, poets, painters, and glass blowers.
It's interesting to observe how the songwriting process has evolved over the last couple decades.
The reason songwriters and producers developed highly iterative processes was because once a song, or album, was committed to a storage medium and widely distributed there wasn't an opportunity for the artist to say "Um... there was an error in the guitar solo on track 3. Please go to our website and download the latest patch".
From a project management perspective, the producer and artists were pursuing perfection on the first and only release of the product.
The advent of Internet sites such as http://www.mp3.com has given musicians access to a feedback loop with their listeners where they now can "fix it in the remix" and repost their songs.
It's almost like having an intimate "onsite customer" providing real time feedback about what they'd like to hear (albeit they aren't paying customers, so the artist still has the final word on what "features" go into the song).
The concept of NonDestructiveEditing? has dramatically changed the creative process. We are now allowed to iterate in many crafts because we can always "undo" any changes we make in a digital storage medium. This was not always the case.
Moved from CanAnArchitectureEmerge
I would like some evidence for the contention that most good soups have an original designer. I would agree that some do, the rest I suspect have come about by incrementally. --TomAyerst
Were the soldiers in the StoneSoup story the architects of the soup?
Is there an Architect for the Barn in an AmishBarnRaising?
Do you architect a newspaper? or music? Who is the architect of a Jazz piece?
No. No. No. No. There isn't one. Further questions?
As for the others, the soldiers were both the customers for the soup (they ate it I assume), the instigators of the process and, one assumes, they had a vision of what was going to happen after they started; so they fit some of the above definitions of architect.
Jazz is an activity performed by a group of skilled practitioners with the aim of creating something. The approximate form of the production can be predicted if you know the piece but not its actuality.
I think I know what Robert is getting at but I want to put some bounds on what Communal, Creative Group Activities definitely don't have architects and which do. Software construction falls somewhere along the line. --Tom Ayerst
How does 'being the architect of someone's downfall' work?
The questions above are interesting in the way they surface the difference between 'architecture' and 'architect'. An 'architect' is a single designer, and 'to architect' is an intentional activity. But 'architecture' describes, in retrospective, designs that got to be. Many of the most important patterns we live with (soup, barns, jazz, etc.) have folk architectures, which means there is no single architect (and therefore no 'architect') whose intent bore these fruits. Yet, the architectures are important.
What the above means is that the soldiers did not create the architecture for the stone soup. The architecture for stone soup is ... Soup. And we all know that the architecture of soup is (usually) hot liquid with (usually) nourishing ingredients in it. The stones and other stuff are not the architecture. The big pot, the large quantity of water, and perhaps the fire are the architecture.
The soldiers may have been the architects of 'stone soup making', meaning the idea of getting others to contribute the more significant parts of the solution, but it is equally likely that it happened by accident.
Many similar arguments can be made about jazz. The succession of seventh chords is the architecture of jazz. The improvisation itself in all its detail is not part of the architecture, although the potential for and expectation of improvisation in a given jazz performance certainly is. -- WaldenMathews
Does that mean there is no architecture in an integration effort? --???
No, I think there is, its just more of a ReferenceArchitecture? as is defined by SoftwareProductLines. --rad
See also JazzMusicMetaphor.
EditText of this page
(last edited February 2, 2003)
or FindPage with title or text search