There's a misconception about jazz that it has no rules, that it's all just a bunch of improvisation. In fact, nothing could be further from the truth. Jazz is about improvisation - within a defined set of rules. Building software is no different. We create for a specific moment in time within a defined set of rules. Jazz is just like that. As a software developer and jazz drummer, I have context for both pursuits. To those outside the software development sphere, it may seem random. We should be forgiving of such misconceptions because they lack context. Our job is to provide that context.
Jazz Has Rules
A typical jazz ensemble is made up of four musicians (a quartet): horn, piano, drums, and bass. Other typical variations can be +/- 1 player - trio and quintet respectively. With fewer players, each player must cover more territory. With more players, although there's less territory for each to cover, there are more communication pathways - many more. Calculating the combinations for four vs. five is easy: 4! & 5!, or 24 &. 120. Not only does adding one more player add complexity, but each of the other players has to kick in a share of the proceeds!
How does the complexity, regardless of level, get managed in jazz? The answer is found in the rules.
Consider the following jazz tunes: “Take the A Train” and “The Girl from Ipanema” are two very different tunes. “Take the A Train” was written in 1939 for Duke Ellington's big band and “The Girl from Ipanema” was written in 1962 in the Brazilian Bossa Nova style that is played with a small ensemble. These are two very different tunes from a listening perspective. But what about a structural perspective? The tunes are structurally identical because they each follow the rules of jazz. In fact, just about everything we encounter has some rule set associated with it. We stop at red lights, we don't put residential developments next to oil refineries, and traffic moves in one direction (sub-rule of which direction is dependent on locale, i.e., context).
What's the rule in the case of these two songs? The rule deals with the structure of the song itself. The form is known as AABA. From the moniker, we can infer that there are four sections. As it turns out, each section is eight bars long (counts of four), for a total of 32. Music, like computer science and everything else in the universe, is based on mathematical principles. It isn't surprising that there's a large crossover between musicians and programmers.
In a standard jazz tune, the first two sections (eight bars each, 16 total) are section A (often referred to as the chorus). The third set of eight bars (or what is often referred to as the middle eight because it's in the middle of two section A instances) is represented by the letter B. The letters A and B are arbitrary. Think of them as proxies (variables) to represent something else, more evidence that music and programming are two sides of the same coin! Just how, then, does structure inform rules?
Specifically, in “Take the A Train” and “The Girl from Ipanema,” the AABA sections are as follows (in seconds):
- “Take the A Train:” A: 0:18 A: 0:29 B: 0:42 A: 0:54
- “The Girl from Ipanema:” A: 0:13 A: 0:28 B: 0:43 A: 1:14
Both are AABA structurally, and yet both are quite different musically. In software, we see the same thing. The jazz analog outlined here doesn't only address how software works. It also addresses how people collaborate to build software. We can learn much from how musicians collaborate, on the fly, in a jazz tune. This is easier to pick up in a live situation because it's happening live, in the moment. When live isn't feasible, that's why we have YouTube!
Reviewing the AABA structure in a performance, the first two sections are the A (chorus) section. Everybody plays. The B section (third section) is an interlude that eventually leads to a bridge that's a way tunes will transition from one mode to another. Typically, this is when players trade places, solo, and improvise. And the players who aren't soloing, they fade to the background and accompany the soloist. This is also known as “comping.” You will see this exchange between different players in different ways. But what's common is the time interval. A solo can be as short as one bar, or can be four, eight, 12, 16 or more bars in length. It all depends on what the song requires, what the mood is in the moment, the facts and circumstances. It's not unlike a typical software project. The key is that regardless of the physical differences, there's a level of physical commonality you can reach that transcends any song such that an abstraction starts to materialize. This becomes a common reference point that each tune will vary from. Those respective variances to that common reference point can be compared, and thus different tunes can be compared and contrasted. The structure, taxonomy, and rules behind jazz and music in general makes that possible. I use this very technique to compare and contrast different software projects.
People and Process
If you've read my work over the past 20 years or so, you've read the phrase “People, process, and tools.” The idea is that that for any process to work, it first requires people to understand and carry out a process. To the extent that the first two things are in place, then, and only then, do tools begin to have efficacy. In other words, even if you have the best horn in the world, if you can't play with others, you can't play at all. And by playing with others, what I mean is knowing and understanding the rules. There must be an agreed upon acceptance of the rules. Imagine a quartet where the drummer and horn player are on one page and the horn and piano player are on another page? It would sound pretty bad!
When there's agreement on the rules (the protocol), information can be exchanged. That's what happens in jazz: There's a call and there's a response. With a four- or eight-bar solo, the horn player may play something for the drummer to respond to. For that to happen, there must be coordination on the rules because in any musical piece, something is being created over time. The players must meet at the same place at the same time for any of it to make sense. And the only way that can happen is if the players are following the same play book. If they are following the same play book, they are following the same rules, and that's a good foundation to build upon to make good music!
But following rules isn't enough. Although our work is pragmatic, there is, in fact, a good deal of creativity to how we solve problems with code. As a team, we work under a common set of rules. Individually, we need the ability to be ourselves. This is the way it is. Just as we all write differently, we all code differently and we all solve problems in different ways, even if those differences are slight. We all need the ability to improvise a bit.
Improvisation
Assuming that players are working within a set of rules (perhaps a framework?), is there flexibility? Indeed, there is. To the outside world, it seems like chaos with different players playing at different times. Typically, jazz tunes are in 4/4 time (four beats to a bar and a quarter note gets one beat.) Variations are 3/4 (waltzes), 6/8, and 5/4 time. The point is that within a tune based on the framework (AABA) that's 32 bars in length, different time signatures may be involved. A great example is the Dave Brubeck tune “Blue Rondo ? la Turk.” It's mostly in 9/8 (nine beats to a bar with an eighth note getting one beat) with transitions to 4/4, and then back to 9/8. If you don't know the tune, listen to it. You'll clearly be able to discern when the tune is in 9/8 vs. 4/4. It's a wild change, but it works and flows well. It's because the players play well together under the rules. I'm also a bit biased because Dave's Brubeck's drummer Joe Morello was one of my teachers!
Within the framework for a given tune, the one thing everybody needs to agree upon is where “one” is. In other words, if a tune is played for a group of people, does everybody agree where the first beat of the four beats in a bar is? One is the north star. You may not be aware that in most jazz tunes, on beats two and four, you'll hear the “Chick” of the high-hat cymbal. As folks are improvising, trading off calls and responses and it's getting increasingly wilder and further from the original tune, somebody needs to “stay home.” That's what the drummer and bass player do. No matter what's going on, folks can listen for the drummer and the high-hat. Two, four, two, four, etc. The soloist knows where the one is by reference. For the whole thing to work, players have to agree on the rules, the velocity (beats per minute), etc. If people agree on the foundational basics and build from there, many opportunities for flexibility will present themselves.
Kind of Like a Sprint in Scrum Perhaps?
Within all of that, there are plenty of places for one to explore and go off in different directions. In the software context, it tends to be a pragmatic, not artistic, pursuit (despite what some artisan programmers may think…). In software, we place a premium on flexibility. How accepting is the system to extension? What are the entry points? Where is the one? Software projects are just a coordinated effort over time to create something, just like jazz.
Any group of people who need to collaborate so that the whole is greater than the sum of its parts must be rhythmically in sync. Things out of phase don't work. Groups not in sync as to time, rules, and structure also don't work. I could just as easily be talking about a jazz quartet or a scrum team. Whether it's how music is composed and played, how cities and urban centers are planned, or nature itself, there are many lessons to be learned that benefit our software.
Take time to look around for inspiration!
JP
