Programming is Not Like Music, As Much As I’d Like It To Be
June 25th, 2009 by Sean Dick
As much as I’d like it to be, music and programming are very different disciplines. That isn’t to say that they aren’t complimentary. I play guitar, and although I probably wouldn’t call myself a musician, I’ve been playing for 16 years and I think that entitles me to an opinion.
To start with, as pointed out in the RailsConf talk by Jonathan Dahl – Five Musical Patterns for Programmers – there are some striking similarities in process for writing music and writing code. I really enjoyed his talk, but I found myself really disagreeing with the premise the more I listened. Programming is like building instruments.
Sure enough, sheet music and source code share a common responsibility. They enable the execution of the intent of the writer. In stark contrast however, once code is written and run it always performs the same while even the oldest and most familiar pieces of sheet music are subject to the interpretation of the player. This is an inextricable part of what makes music so compelling and conversely why we can depend on (good) code to provide us with consistent functionality.
But wait, you say, when I use flickr or facebook or twitter or any other running body of code, the input I give it changes the experience. But I would counter by saying it’s more akin to the way a musical instrument itself is largely agnostic to the music you decide to play on it. Photos I upload to flickr or inane details of my workaday life I post to twitter are bound by the form the running code creates. In much the same way a piano cannot sound like a banjo any more than I can post more than 140 characters at a time to twitter, code defines timbre.
“The quality or tone distinguishing voices or instruments; tone color; clang tint; as, the timbre of the voice; the timbre of a violin.”
I have been on a low-intensity hunt for a new guitar. Currently I have a low-cost but serviceable Yamaha that has served me well since I moved here. A well-made instrument can make the difference between a good performance and a great one. Although it’s entirely possible to play even the best-made instrument poorly, that doesn’t change our perception that the instrument itself is capable of producing beautiful music. The quality of tone is the product of a number of factors in the build and maintenance of an instrument, likewise with code. When we do our job well we produce tools that enhance and complement the abilities of our users. To continue the instrument metaphor, we all set out to make a Stradivarius or a Steinway, but sometimes we end up making Squier II Strats.
How do we avoid this? The first step is to test-drive. A luthier checks his work constantly, verifying that the instrument performs well against conventional standards and that it is internally consistent to the best of the instrument’s ability. The same goes for piano makers (if they have a special name I am sorry, I don’t know it.) and more to the point, programmers. This is a matter of craft and adherence to best-practices in development. And finally, it is vitally important that most all of the work done is seen by at least two pairs of eyes. Granted that we generally pair program at Market7, I can only recall a few times when a peer review hasn’t improved the quality of code delivered.
