Did you ever notice how many of the programmers you know are also musicians? It seems that every coder I meet is also a jazz guitarist or a classical pianist. When I meet people in IT these days, sooner or later I ask what instruments they play. And as often as not, they confess that they are amateur musicians or part-time musicians or former musicians. The correlation is far too high to be a coincidence.
I was never that great a coder – nor, truth be told, that great a jazz musician – but I made my living in each of these fields for a few years before I stumbled into the less demanding world of high-tech journalism. For the next decade or two, all it took was a couple beers to evoke my canned speechlet about the parallels between music and code.
The essence of my little rant was this: Both music and software rely upon the creator's ability to exercise creativity within a framework of rigorous rules.
It's not much of an observation, as it turns out. It's true – but the same is true of almost any nontrivial human activity. I think we humans are drawn to this kind of complexity. It's part of what defines us as a species.
I'm not the first or the only commentator to notice that many musicians are programmers and vice-versa, by the way. A quick look around the Web reveals that I stand upon well-trod ground:
Well, you get the idea. I hadn't read any of these when I “invented” the insight years ago, but as you can see, it's a fairly obvious observation for anyone who's got a foot in both worlds.
Many of life's little insights turn out to be interesting for a moment or two, but ultimately without value. Still, I keep returning to this one. It must be true that musicians and coders can learn from each other. Techniques that help us manage creativity and complexity in music ought to be adaptable to coding, and vice-versa.
As it turns out, I'm not the only one to have that thought either. Musician/programmer Adrian Cho has written a book called The Jazz Process, in which he seeks to distill the factors that allow jazz musicians to collaborate and improvise successfully, and makes those factors accessible to software developers and other practitioners of the high-tech arts. Cho has contributed articles to Dr. Dobb's and other publications, in which he sketches out his ideas.
The bullet-list of Cho's principles reads a lot like the 12 Principles of Agile Software, which supports my gut-level reaction that he is on to something:
-
Use just enough rules
-
Employ top talent
-
Put the team first
-
Build trust and respect
-
Commit with passion
-
Listen for change
-
Lead on demand
-
Act transparently
-
Make contributions count
-
Reduce friction
-
Maintain momentum
-
Stay healthy
-
Exchange ideas
-
Take measured risks
The Jazz Process may not be as complete or as useful as Scrum or even Kanban, but I think Cho's insights are valid and thought-provoking. I'm just jealous because he wrote the book before I got around to it.
Web recommendation: The extraordinary Kent Beck is the creator of design patterns, extreme programming, and test-driven development. His Three Rivers Institute Web site is a cornucopia of fascinating insights, thought-provoking publications, and research results. (It is also, like so many of the software gurus' Web sites I have commended to you these past weeks, lamentably lacking in design. What's the deal with programming geniuses and lousy Web-design skills?) J.D. says check it out.
J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He recently relocated to a small town outside Belgrade – stop by if your travels take you through Serbia.