Improvised Software - Version II - Iteration I | Iteration II
My original plan was to put up iteration after iteration, an excercise in agile writing. Given that Iteration I was some months ago and I haven't touched it, it appears that I designed too much up front and now have a big legacy piece of *(&^(. Since I have the luxury of dictating the budget for this project, I'm going to opt to rewrite, and do it in small steps.
Here's the first story: the blog entry should describe improvisation.
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. We improvise in music by using scales, chords and common idioms to (one might argue) convey ideas.
We improvise in software in the same way. 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.
!commentForm
Improvised Software - Version II - Iteration I
My original plan was to put up iteration after iteration, an excercise in agile writing. Given that Iteration I was some months ago and I haven't touched it, it appears that I designed too much up front and now have a big legacy piece of *(&^(. Since I have the luxury of dictating the budget for this project, I'm going to opt to rewrite, and do it in small steps.
Here's the first story: the blog entry should describe improvisation.
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. We improvise in music by using scales, chords and common idioms to (one might argue) convey ideas.
We improvise in software in the same way. 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.
!commentForm
I think software is more like composing music rather than improvising it. One can argue that improvisation is a form of spontaneous composition, but in improvised music you don't get a chance to refine a half baked idea. The best you can do is repeat it and throw in some variations ( play off yourself ).
In software development as I see it, especially when working agile, you sketch a rough draft and continue to refine it until it reaches a certain level, and then you move on to the next requirement/idea.
Perhaps composed music or painting are more suitable metaphors than improvised music?
In software development as I see it, especially when working agile, you sketch a rough draft and continue to refine it until it reaches a certain level, and then you move on to the next requirement/idea.
Perhaps composed music or painting are more suitable metaphors than improvised music?
The composition metaphor works for me as well, but I think there's a lot of gray between composition and improvisation. Back in the 1700's musicians were improvisors. The written music (often figured bass) was like a UML document but the "music" (the code) existed ONLY in the moment in which it was being performed, and while the guide posts were consistent (melodic themes, chord progressions) from performance to performance the turns and flourishes changed quite frequently - hence the differences in printed music (based on editorial understanding of what was likely played).
Conversely, modern improvisors develop a repertoire of melodic themes and harmonic concepts that are repeated night after night after night after night. In some cases, improvisors will have parts of solos that they play exactly the same way for years - while other parts of the solos change from night to night. The point being that there is an element of somewhat static composition that exists in improvised music.
"The code is the design" resonates very strongly with me. Early on in a project you may find yourself able to move on to the next requirement and not revisit the code you just wrote, but it doesn't take long before designs that were completely relevant last iteration are no longer relevant - so the design changes to make it more relevant - just as an improvising guitarist (me) reacts to a particular rhythm that the particular drummer plays in the heat of the moment of a performance.
So while I agree that there is an element of static composition in software, I think it lives side by side with its improvised brethren.
Conversely, modern improvisors develop a repertoire of melodic themes and harmonic concepts that are repeated night after night after night after night. In some cases, improvisors will have parts of solos that they play exactly the same way for years - while other parts of the solos change from night to night. The point being that there is an element of somewhat static composition that exists in improvised music.
"The code is the design" resonates very strongly with me. Early on in a project you may find yourself able to move on to the next requirement and not revisit the code you just wrote, but it doesn't take long before designs that were completely relevant last iteration are no longer relevant - so the design changes to make it more relevant - just as an improvising guitarist (me) reacts to a particular rhythm that the particular drummer plays in the heat of the moment of a performance.
So while I agree that there is an element of static composition in software, I think it lives side by side with its improvised brethren.
> in improvised music you don't get a chance to refine a half baked idea.
I disagree. When I'm soloing, if I make a "mistake", I go back and rework it (push it through a horn until it gets worn into a new note). Try to logically reconnect it with the context. Then it's not a mistake anymore. One of the things I love to see in musical improvisation (as well as comedy improv) is a performer thinking in real time - refactoring on the fly. What could be more agile?
Del Close invented a "long form" of improv called "The Harold". A really sophisticated dramatic structure (~= application architecture) would emerge from "bottom-up" improv (based on minimal suggestions from the audience ~= XP stories) when the players were strict about adhering to some basic rules (~= best OO practices).
I disagree. When I'm soloing, if I make a "mistake", I go back and rework it (push it through a horn until it gets worn into a new note). Try to logically reconnect it with the context. Then it's not a mistake anymore. One of the things I love to see in musical improvisation (as well as comedy improv) is a performer thinking in real time - refactoring on the fly. What could be more agile?
Del Close invented a "long form" of improv called "The Harold". A really sophisticated dramatic structure (~= application architecture) would emerge from "bottom-up" improv (based on minimal suggestions from the audience ~= XP stories) when the players were strict about adhering to some basic rules (~= best OO practices).
I really like this. I had never thought of development in this way before, though being a jazz saxaphonist that never quite liked playing music that was written down, it really speaks to me. It gives me a number of other metaphors to think about. The first that comes to mind is pair programming == trading fours (two players trading off a solo every 4 bars, building their ideas on top of the others). I'll have to think about this some more... very interesting.
Add Child Page to ImprovisedSoftwareVersionTwoIterationOne