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

[interview]

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.

About the author

Jonathan Vanian's picture Jonathan Vanian

Jonathan Vanian is an online editor who edits, writes, interviews, and helps turn the many cranks at StickyMinds, TechWell, AgileConnection, and CMCrossroads. He has worked for newspapers, websites, and a magazine, and is not as scared of the demise of the written word as others may appear to be. Software and high technology never cease to amaze him.

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09