Playing Jazz with Test-Driven Development

In a former life, I was a musician.  A pretty serious musician, actually.  I spent a year in college as a music major, did time in various bar bands, cover bands, and coffee house sets after college, and even spent some time in a jazz band.  And jazz, is where I find myself returning to time and time again.

Any musician who is also a developer, and I've noticed that there are an inordinate amount, will tell you that there are many, many parallels between the art of software development and the art of musicianship.  One of those parallels is something that I've noticed only recently but would like to discuss here:  playing jazz and test-driven development.

One of the common misconceptions about jazz musicians from those unfamiliar with the genre is that jazz is simply about "making it up" as you go along.  Although this is true in one sense, a more appropriate word is probably improvisation.  You see, jazz has the unfortunate stigma that since there aren't exact notes you're supposed to be playing at a certain time that jazz requires no real knowledge of music.  In fact, nothing could be further from the truth.  You see, "making it up" is not necessarily a fair explanation because that implies that playing anything would work in every situation.  This is simply not true.  An competent jazz musician must constantly be paying attention to the other components in action in the song.  The key, the chord progression, the meter, it's all equally important.  Beyond this, a jazz musician is also expected to constantly be listening to the other musicians at work around him as to not conflict or step on what they're trying to say.  Only then can a musician make an educated decision about what to play at any moment.  In order, to make these decisions appropriate to the given situation, a musician must have an extensive knowledge of all of the different techniques available in music.  They must know innately as many keys, common progressions, and modes as possible.  They must be an encyclopedia of different styles of music and know when to draw on each accordingly.  And they must constantly be searching for more techniques and styles to fill their toolbox with.  In fact, some would argue, that the art jazz requires the most knowledge, and more importantly discipline, of any genre of music today.

It is here, that I start to see the similarity between the perception of test-driven development and jazz.  You see, many people who aren't regular practitioners of TDD, tend to believe that those of us who do practice it simply do not have the patience or discipline to learn a more rigid development style.  Some would argue that TDD is simply an excuse not to spend the time learning more seasoned design practices and techniques.  I think that nothing is further from the truth.  TDD is not about simply "making it up" as you go along.  TDD is about evaluating the current situation with all of the knowledge that you have available that given point of time, and then making a decision towards implementation.  More importantly, TDD is about having the discipline to develop your code in such a manner so that you have the flexibility to change it later when you realize that you've made a mistake.  And above all TDD is about using those mistakes to create a more solid design than you would have had otherwise. 

However, in order to make the best decision that you can given the knowledge of the problem that you currently have, you need to have extensive knowledge of the fundamentals of software development.  You need to know innately both the fundamentals and the more fringe techniques of object oriented development.  You need to have a deep understanding and appreciation for interface oriented design.  You brain needs to be filled with an extensive as possible catalog of both design patterns and refactorings.  Only when you have these tools in your toolbox, can you begin to make educated decisions about what code to write where.  And just as an A-List jazz musician constantly needs to be checking out other players, and listening both classic and new recordings to expand their own repertoire, you as a TDD practitioner need to constantly be reading others' code and scouring the sources of successful open source projects in order to constantly be expanding on your own repertoire of code.  Although this prescription of study is probably important for any software developer regardless of their particular slant or technique, I believe that nowhere can it be more continuously applied than with TDD.

Because only when you have filled you mind with the most extensive repertoire available can you truly begin to "play jazz".