Improvised Software - Version II - Iteration I | Iteration II
OK - got some nice feedback on iteration one. Here are a couple of new stories:
story 2 - the blog entry should describe the collaborative nature of group improvisation.
story 3 - the blog entry should compare the relationships between an improvisor and the song to the coder and the stories
Again, readers may provide green, red or yellow bars in the form of comments below.
Improvisation is the art of using existing tools, skills and experience to spontaneously create something relevant to the current context.
We improvise when we converse - using words, grammar and common idioms to convey ideas and (and this is really important) respond to ideas presented by others - all in context - all without batting an eye.
We improvise in music in the same way. The tools are scales, chords and common idioms, but the conversation (at its highest levels) is just like the spoken conversation. One player presents an idea, another responds in kind. Sometimes others might accent a note here or play a contrasting chord there for emphasis, all in support of moving the idea forward. There are many different dynamics going on. I don't mean the musical term (i.e. relative volume and emphasis) but rather the relationships between all of the players.
There's the relationship between whomever is the featured improviser (thinking more traditional jazz improvisation here) and the rest of the band. There are the individual relationships in different parts of the band (i.e. the drummer and bass player often have a special bond that is separate from the group while being part of the group).
And then there's the more abstract relationship between the player and the song. For those who are not musicians or improvisers, this may be a bit tricky to understand but I'll try to explain. Do you sing along with songs on the radio? Probably not the first time you hear it, but after a few listenings you can remember what comes next before you actually hear it. Imagine if you were singing along with the radio and the power suddenly went out. In your mind, supported by your memory of the song, the song keeps going - and you can keep singing it and imagine the rest of the band playing along.
Well, when musicians improvise "on a tune" they do the same thing. In their mind are the notes and the chords of the song, and they can pretty much "hear" that all going on in their head while they play notes for you - so they have all of that context, even though you may or may not.
I believe that we improvise in software in the same ways that we do in music. There are many ways to express an idea in software, and so we tap into our tools, skills and experience to express the idea in the way that is most relevant to the context. There are different relationships between "players" that affect the code we write. Sometimes its two people pairing. One reader commented on this in the last iteration of ISV2 - that pairing is a lot like trading 4's.
For those who have no idea what that is, it just means that two or more improvisers take turns improvising for a specific amount of time. This can take on a lot of different dynamics - sometimes the soloists will build on what the previous player played. Sometimes it becomes a sort of cutting session - a bit of one-ups-manship. Sometimes the lines of when one player's four bars ends and the next begins starts to blur and the players eventually play over each other. At its worst, this can be pure cacaphony, but at its best its a magical spontaneous duet.
Pairing can take on all of these dynamics. Sometimes one coder writes for a while, test, code, test, code until the other takes over. Sometimes one person writes all the tests and the other writes all the code to pass the tests. Sometimes one writes a test, the next writes code to pass the test and then the next test. Sometimes there's the same sort of one-upsmanship - trying to out-do each other by getting tests to pass more quickly and with fewer lines of code. And sometimes it loses all of this structure and the keyboard starts flying back and forth.
There are other relationships in software, between coders and customers and testers, etc. But there is also that abstract relationship between the coder and the code. Whether you're pairing or going solo, whether you're writing test first or not, there's always this moment when you imagine what the code will be - then you write it - and THEN you get to LOOK at it! And if you look carefully, it usually tells you something. It provides context for your next move. It smells funny and sparks a change in direction. Or it reveals a new direction in the design that you hadn't even considered moments before.
Just like the musician imagining the song in her mind - she conceives of the note, plays it and then there is this moment that's difficult to describe where it begins and where it ends - but the note just played and the note you're playing now and the note you're ABOUT to play all live together in one beautiful moment with part of the song in the back of your mind as context - just like the code you just wrote, the code you're writing right now, the code you're about to write and the stories that provide the motivation for all of this creation.
!commentForm
Improvised Software - Version II - Iteration II
OK - got some nice feedback on iteration one. Here are a couple of new stories:
story 2 - the blog entry should describe the collaborative nature of group improvisation.
story 3 - the blog entry should compare the relationships between an improvisor and the song to the coder and the stories
Again, readers may provide green, red or yellow bars in the form of comments below.
Improvisation is the art of using existing tools, skills and experience to spontaneously create something relevant to the current context.
We improvise when we converse - using words, grammar and common idioms to convey ideas and (and this is really important) respond to ideas presented by others - all in context - all without batting an eye.
We improvise in music in the same way. The tools are scales, chords and common idioms, but the conversation (at its highest levels) is just like the spoken conversation. One player presents an idea, another responds in kind. Sometimes others might accent a note here or play a contrasting chord there for emphasis, all in support of moving the idea forward. There are many different dynamics going on. I don't mean the musical term (i.e. relative volume and emphasis) but rather the relationships between all of the players.
There's the relationship between whomever is the featured improviser (thinking more traditional jazz improvisation here) and the rest of the band. There are the individual relationships in different parts of the band (i.e. the drummer and bass player often have a special bond that is separate from the group while being part of the group).
And then there's the more abstract relationship between the player and the song. For those who are not musicians or improvisers, this may be a bit tricky to understand but I'll try to explain. Do you sing along with songs on the radio? Probably not the first time you hear it, but after a few listenings you can remember what comes next before you actually hear it. Imagine if you were singing along with the radio and the power suddenly went out. In your mind, supported by your memory of the song, the song keeps going - and you can keep singing it and imagine the rest of the band playing along.
Well, when musicians improvise "on a tune" they do the same thing. In their mind are the notes and the chords of the song, and they can pretty much "hear" that all going on in their head while they play notes for you - so they have all of that context, even though you may or may not.
I believe that we improvise in software in the same ways that we do in music. There are many ways to express an idea in software, and so we tap into our tools, skills and experience to express the idea in the way that is most relevant to the context. There are different relationships between "players" that affect the code we write. Sometimes its two people pairing. One reader commented on this in the last iteration of ISV2 - that pairing is a lot like trading 4's.
For those who have no idea what that is, it just means that two or more improvisers take turns improvising for a specific amount of time. This can take on a lot of different dynamics - sometimes the soloists will build on what the previous player played. Sometimes it becomes a sort of cutting session - a bit of one-ups-manship. Sometimes the lines of when one player's four bars ends and the next begins starts to blur and the players eventually play over each other. At its worst, this can be pure cacaphony, but at its best its a magical spontaneous duet.
Pairing can take on all of these dynamics. Sometimes one coder writes for a while, test, code, test, code until the other takes over. Sometimes one person writes all the tests and the other writes all the code to pass the tests. Sometimes one writes a test, the next writes code to pass the test and then the next test. Sometimes there's the same sort of one-upsmanship - trying to out-do each other by getting tests to pass more quickly and with fewer lines of code. And sometimes it loses all of this structure and the keyboard starts flying back and forth.
There are other relationships in software, between coders and customers and testers, etc. But there is also that abstract relationship between the coder and the code. Whether you're pairing or going solo, whether you're writing test first or not, there's always this moment when you imagine what the code will be - then you write it - and THEN you get to LOOK at it! And if you look carefully, it usually tells you something. It provides context for your next move. It smells funny and sparks a change in direction. Or it reveals a new direction in the design that you hadn't even considered moments before.
Just like the musician imagining the song in her mind - she conceives of the note, plays it and then there is this moment that's difficult to describe where it begins and where it ends - but the note just played and the note you're playing now and the note you're ABOUT to play all live together in one beautiful moment with part of the song in the back of your mind as context - just like the code you just wrote, the code you're writing right now, the code you're about to write and the stories that provide the motivation for all of this creation.
!commentForm
Appreciation of a fine wine belongs to the experienced palate; improvision belongs to those who have a mastery of the rules and an instinct for breaking them, to the advantage of the song. Improvisation is quite impossible without the true creative spark, which you've aptly described in your abstract relationship between the coder and the code.
>> the note just played and the note you're playing now and the note you're ABOUT to play all live together in one beautiful moment
I like that - it's like the fourth dimensional analog to Flatland - the 4D being sees along the time axis in both directions at once. A pattern in time - a gestalt.
Here's another thought - the rhythmic cycle of tension building with the test and releasing with the code - strikes me as a II-V7-I cadence, where the minot II is the first shock of the failing test, the V7 is the same test evolving until it fails precisely where and why we want it to, making it ready to resolve into the tonic state (I) - the code "fixed" and the test passing.
I like that - it's like the fourth dimensional analog to Flatland - the 4D being sees along the time axis in both directions at once. A pattern in time - a gestalt.
Here's another thought - the rhythmic cycle of tension building with the test and releasing with the code - strikes me as a II-V7-I cadence, where the minot II is the first shock of the failing test, the V7 is the same test evolving until it fails precisely where and why we want it to, making it ready to resolve into the tonic state (I) - the code "fixed" and the test passing.
Tom - I like this idea of cadence a lot. We talk about rhythm in TDD, but not the tension and release implied by cadences. This is the same thing that happens when you're watching a great movie - especially a good suspense film. Relax, tense, more tension, relax, tense, more tension, etc. True of sports as well. When the game is good. Ever watch an exciting tennis match. When its the nearing the end of the third set of three and every point is exciting. But some, when the volley goes on and on, are more exciting - they build up tension the longer they go - and then applause regardless of who gets the point. This is not just because people are behind the player who won the point. Its because everyone is so relieved that the point is over and they can, for at least a few moments, sit back and relax. Until the next test....
Add Child Page to ImprovisedSoftwareVersionTwoIterationTwo