One more music post

I think I've mentioned before that I'm on the alumni board for the school of arts and humanities at my alma mater. I'm one of the few people on the board, however, that isn't still working in the arts - I think I was invited, in fact,because working at Microsoft seems so different from composing music (I have a BA and MM in music composition / theory).

The sad truth is that composing music and writing computer programs is that they are quite similar. I hear testers talk all the time about how "testing is a creative process", or "testers must be creative", but those statements are a little silly in my mind - you need to be creative to be successful in any job. Shoot - I'm having a hard time finding any job that doesn't require some bit of creativity. When I used to deliver pizza, it was up to me (and my oh-so-creative mind to figure out which pizza to deliver first based on both route and order time. I could tell you a dozen stories of creativity from my (brief) career as a bicycle messenger as well.

"But composing music," you ask, "that must be extraordinarily creative?" I can tell you that it feels creative - and it's fun too, and that it's exciting to make something that pleases people (damn - doesn't that sound like software too?). Of course there's a creative aspect to composing anything from opera to pop, but a huge chunk of the work isn't much more than rote work. Let me explain.

When composing, sometimes I start with a melody. I may "hear"  a melody in my head, poke around and fine one on piano or another instrument, or I may start with a specific scale in mind. Once I have some melody ideas or fragments, I spend a bit of time analyzing the melody to see if there are particular chord progressions implied. From there, I may build a matrix of alternate chord progressions that can support the melody. I'll also continue to play with the melody  - replaying it in different modes and rhythms until I get a good idea of how many ways it can be used. If you were paying attention you'll notice that only a fraction of the time so far was spent discovering a melody - the rest of the time was a structured process I go through to make sure I understand how I'm going to build a roadmap / strategy for the rest of the composition.

From here, it's almost all math. Orchestration (arranging) was my specialty, and I realize today that it was the math geek in me trying to escape (Incidentally, when I was working on my masters degree and getting interested in computers, my "dream job" was a job at one of the arranging houses in LA - I wanted to use computers to write music, even if it wasn't my own). Arranging music - understanding chords, voicings, instrument ranges and timbres, etc, is just about all math. If you've ever played in, or listened to a jazz big band, think of the saxophone "feature" - aka, the sax soli, where the saxophone section plays for a while by themselves. The creative part (and the key to a good soli) is to write a good lead line for the lead alto saxophone player. From there, it's almost always a "4-way tight, 2nd voice drop" arrangement - in other words, all math. There is some creativity involved if the voicing leads one of the instruments outside of it's range and you need to create a way (other than an octave jump) to get back on track.

The musicians probably see the parallels, but I'll spell a few out. When I write code, there's a creative part up front where I figure out what I'm trying to create and establish the framework / design for whatever I'm doing. Once I have that in place, as long as I have a good understanding of the fundamentals and patterns, I just implement what I've designed. Implementation is easy - it just requires that I know the idioms of whatever language I'm writing in. This is true for application development as well as test development.

This is long already, but I have one more jump to make. I love music theory and arranging music - knowing why music is structured the way it is and applying that knowledge (sometimes in creative ways). Unfortunately, this makes me a critic of a lot of music, because I hear structural musical ideas applied in ways that don't make sense to me (I was going to write "wrong", but I gave the bad music the benefit of the doubt).

I also love testing software - I know the theory of how it should be put together, and love testing it (sometimes in creative ways) to make sure it adheres to those structures. I like to find places where it's done wrong (no benefit of the doubt for bad software), and, because I'm in a position to make a difference, find out how to make it better.

I'm done with analogies for a while - thanks for bearing with me.

Comments (4)

  1. It’s always interesting to hear how a colleague writes music. It’s a complex ansd personal process; thanks for sharing.

  2. Thanks for sharing the analogy (and your knowledge of composing music)!

    I think that when testing, we can be creative not only when coming up with test ideas but also when executing those ideas e.g. by combining the common parts of separate tests, eliminating unnecessary steps. We could drive ourselves to be more efficient in test execution by giving ourselves lesser time than before. Alan, do you agree to this?

    Inder P Singh

  3. Alan Page says:

    > We could drive ourselves to be more efficient in test execution by giving ourselves lesser time than before.

    There’s an axiom that I’m too lazy to look up that says that "work will expand to fill all available time". If that’s true, I suppose it makese sense that the reverse is also true.

    I’d have to think about this a bit more, but my hunch is that you’re correct. If we had less time, we would undoubtedly be more efficient with that time. I know it’s true in my personal projects, so it makes sense that it would apply to a team effort as well.

    Of course, the more efficient your current state is, the less impact reducing time will do to improve your efficiency. If you’re already somewhat efficient, less time for execution may not make a difference – or worse, the panic may cause you to be less efficient.

Skip to main content