How Producing Code Is Like Producing Music (and a Message for the Agile Evangelists): An Interview with David Hussman

David Hussman has a fruitful career in software development, with most of us recognizing him as being an accomplished agile coach and owner of the Minneapolis-based consulting group Dev Jam. However, in his earlier years, David spent the bulk of his time recording and playing music, for a while attacking his guitar in the glam-metal band Slave Raider. In this interview, David discusses the similarities between producing music and producing code, the Frank Zappa of the software world, and why he wants agile evangelists to “shut up and play your guitar.”

Jonathan Vanian: Tell me about your life in music.

David Hussman: When I was a kid, I wanted to be like Ted Nugent or Jimi Hendrix or Brian May or Eddie Van Halen. I’m from Minnesota, and I thought I better go to school and get a job. So I went to this little electronic school, and then I was like, screw that, I want to rock. I just bailed at everything and was in this super weird band for a while, and then I got into, kind of like a big hair-metal band in the '80s. I always kind of wanted it to be a David Bowie meets Alice Cooper thing, but it kind of turned into Kiss meets All Star Wrestling.

I then got a record deal, and it was pretty cool. I started hanging out in all these recording studios, and because I had the electronics background and I was a musician, I was a shoo-in to be a producer. So I built this studio in Minneapolis, which was a hot bed of music. We had Soul Asylum, The Replacements, the Jayhawks, and just lots of good stuff going on. I met all these singer-songwriters, and I ended up working out of Prince’s studio at Paisley Park and doing independent records, where for [bands], it was a big budget because it was a couple hundred thousand dollars. And then I kind of burned out, because I ran into too many “bizmicians.”

I think it’s why, on my better days, I do well now. Because I just look at producing software like producing music. It’s just a different medium.

JV: How is record producing is similar to what you are doing now?

DH: I’ve always thought there’s a real strong correlation between software and music that’s more than just the simplistic stuff that’s drawn all the time. Very few people can pull up a sheet of music and say, “That’s a beautiful song.” Reality says that music is measured when it’s played. If you look at code—especially the syntax—very few people can print out a huge program or a large system and say, “Boy, that’s going to be a great user experience.” Most of us mortals have to use the software.

Where the music world is creative, I think the software world is the same way. When you’re producing a record—time, money, and egos are at play. For a producer, you have to figure out how to tell people, “I’m sorry. The tambourine track is over. No one cares about that, but you.” You have to have some kind of structure and order, but if you put too much structure in, you homogenize the music into something that’s uninteresting. I think we do that in the software world, like the heavy process stuff. People are so worried about all the wrong things.

The agile world is victim to the same thing now. I go into these places where there are these Scrum lawyers, and the Scrum lawyers are like, “On article six, page five of the Scrum Bible, blah, blah, blah.” I did this talk in New York a while ago where I compared Ward Cunningham to Frank Zappa. Frank Zappa did this album called “Shut Up 'n Play Yer Guitar,” and I think Ward is kind of a software version of Zappa. Zappa cares about what the music sounds like, and Ward is all about learning from evidence. It’s a little bit harder to refactor in music, but there’s a similar parallel there. If you get the fundamental tracks right—like if the bass and the drum tracks in the raw cut are solid—you can start layering on top of it. I think there is a really strong parallel in code. The people that have never written software at the fundamental level don’t understand that if you don’t get the first couple thousand lines going in the right direction, then it’s really hard to fix it in the mix. I swear to God man, sometimes we call things refactoring that we should call garbage collection. If things suck, refactoring becomes a euphemism.

JV: What is the fine line between something being an empty ritual and something that you would actually put into practice?

DH: There’s a studio in downtown Minneapolis where I worked with a guy named David Z.—his real name is David Rivkin [ed. note—the brother of Bobby Z., a music producer and former member of Prince’s band]. So a new piece of gear would come to the studio, and he’d plug it in and wouldn’t read the manual. He’d take some sound that he knew—whether it was a snare drum, a guitar, or a mix—and would plug that into this piece of gear, and he would start spinning through the presets to learn what it sounds like. If it sounded bad, he would say that he didn’t want to read the manual. I think his point was that he shouldn’t have to read the manual to figure out why this was a good device for him to use as a producer.

I think that’s what goes wrong in the Scrum world. People don’t spin through the practices to see if they sound good. In the process world of software, people get so wrapped into “are we doing the process right?” that they stop thinking about if it is producing the right results. It’s kind of like: out comes over-process.

When I’ve been doing larger adoptions with big companies, my goal is to not make everyone do Scrum. In fact, I’ve been going into these large organizations saying, “So we’re going to try and get fifteen teams to work together?” First of all, that’s a hard problem. Agile Schmagile. Second of all, let’s make sure that we are going to figure out how to use agile methods as a tool. If you have fifteen teams and you are trying to synchronize across those, iterations are more like synchronization [efforts], and you want to make sure that all the teams are producing the same results. Whether Team A is using Scrum, Kanban, XP, or whatever—I don’t necessarily care. It’s a mistake to say that if everybody does the same thing, we’ll have success.

JV: It’s kind of like people thinking that they can sound like the Beatles by using the same recording gear the Beatles used.

DH: Totally. When I was in the band days, I got to go to all these concerts. One of the concerts I went to was Van Halen opening for Ted Nugent. This is the early days, and Nugent heard Van Halen’s guitar tone and was like, “Holy smack, what is that guy playing through?” And so, Nugent’s roadie tells me that Van Halen went off stage and—this is like having a date with someone’s girlfriend: to play through an amp without telling them—it’s not very cool. So Nugent plugged into Van Halen’s amp, and I said, “Wow! What did it sound like?” And [the roadie] said, “Sounds like Ted Nugent.”

I think the mistake is, “Let’s have everyone do Scrum. Therego, we’ll have success.” Based on what? What kind of science did you guys study at school. That’s not what I learned.

JV: When you’re coaching companies, how do you go about prescribing some of the different methodologies?

DH: I think a lot of my early success with agile and extreme programming was, by and large, due to happy accidents. I attributed my success to using a process, and then I had a couple projects blow up hard on me, and I thought, what happened? Then I realized that I didn’t map the process to the context, and I think that’s an essential part of coaching. Understanding how people work today, what they do well, what their real challenges are, and then what their motives, or motifs, are.

I do these series of interviews, and this is actually part of this video series that I did for the Pragmatic Programmers. The first of three videos is on assessments and interviews, the second one is on selecting and suggesting practices, and the third one is on planning to coach. These coaching plans that I’ve put together say, “Here’s what I heard you guys say in the interview, this is my understanding of your context. Therefore, I think these practices will help address the issues that I either discovered or you named.” They’re either going to help you amplify what you do well or they’re going to go right after the challenges you have. That’s what kind of bugs me about the agile evangelist people. It’s always like, “Have faith. It will be great.” Shut up and play your guitar.