Saturday, February 10, 2007

Software development lessons applied to music production, and music production lessons applied to software development, pt 1

Some background.

I became a professional programmer straight out of college, coding on the IBM system/38 and AS/400 (now iSeries i5 System i platform). In my spare time I'd code 3D animation in assembly language, teach myself C++, and later eventually HTML and all the web goodies.

And, after working for someone else for a few years, I decided I had to run my own business. There's no other way to describe the need to be self-employed other than as a need to be self-employed. And so, I struck out on my own and started a small company that contracted programmers (including myself) to IBM midrange systems shops.

Now also during this time, I had to have music in my life. I had to be a musician. There's no other way to explain this calling other than to say it was a need, a drive, and I had to do it. Simple, no? And so... while I was coding, drumming up new clients, learning new-to-me languages, and writing .asm code for an early-90s demogroup, I attended piano lessons and jazz ensemble classes and performed around town.

My apartment was comprised of a bedroom, a kitchen, and a stockpile of computers, technical manuals, synthesizers samplers and keyboards, many bags of coffee and a bottle of single-malt whiskey.

Hey, my senior project in college for my C.S. degree was writing my own MIDI sequencer on a fat Mac in 68000 assembly! Hello? 1986 on the phone for you, line one...

Music and computers.. huge in my life, and I didn't have the sense to pick one over the other. So I did both.

It was only a matter of time before I decided to start a second business, and that was music production and publishing. (It later became music licensing and sound design, and thus my first lesson of entrepreneurship: be willing to sail with the wind, and not against it).

After a few years, I noticed more than a few similarities between successful software development and engineering projects and successful music production projects. I'll share some of these observations in this article and in subsequent articles.


Choose the right people: find good people and throw out the rest.
I observed many horrible ways to run projects while I was a contract programmer, and a few good ways. You can learn a lot by watching, or being involved in, a disaster and that's exactly what I did - experienced disasters and so learned a lot! If you work in enough shops, you can very quickly learn what is and isn't good project management and practice.

My father's first advice to me early on when I had my own project to run was "Rule number one: don't mess with people". Er, he used an entirely different and much more colorful word that "mess" when he said it, but you get the drift. This brings us to the first lesson:

Find and work with the right partner(s).
Lets face it - no one likes to work for an [EXPLETIVE DELETED]. We don't always have a choice, of course, but if you can help it, avoid 'em. This also goes for the people with whom you work, and who work for you! My colleagues and I have a rule, decided upon sometime after our collective 38th birthdays: "No more working for/with [EXPLETIVE DELETED]s!" It may mean short-term lost income, but has not meant lost opportunities whatsoever. Another opportunity always seems to pop up.

What I noticed as a contract programmer was that most of the time, the projects that failed were run by said unpleasant personalities. On very rare occasion, someone was so smart and possessed with ability that you simply figured out a way to deal with their steel-wool social skills. A vast majority of the time, a single aberrant personality could sink a project very, very quickly. Ditto for music production: a troll in the control room usually meant disaster, or at the very least a lot of extra time (and money) fixing Mr. Troll's damage.

And in a small shop or group, or godferbid in a startup, it's completely deadly to the project/startup. So choose wisely. Find people who have similar values, similar goals, and are preferably smarter than you are in some areas of expertise. Avoid toxic people.. they're toxic. [DuH! -ed]

This is vitally important for a number of reasons, many of which aren't clearly tangible. Projects of any kind are incubators for stress, pressure, anxiety, doubt... do you really want to be harnessed to a complete jerk during these times? At one-in-the-morning the day before a launch or release? When nothing's working right? When you feel that all of the music or code you've just been creating totally sucks? And this may sound strange, but the ability to pick up the phone & talk to your trusted, respected, smart co-founder simply to hear "don't worry", or get a reiteration of the project focus, or blue-sky new ideas and/or narrow down the existing ones, or dismiss some doubts, is huge. At least to me, it is. And remember, you may find that you also provide the same occasional duty for him or her.

This also may mean cutting certain people out of your life: the nay-sayers, the "Yes, But Did You Think About How You're Going To Do [x]" advisers, the free-advice relatives, the leeches, the coat-tailers, and so on. Anyone who's a psychological (or physical!) obstacle between you and success - dump 'em.

Surround yourself with people you look up to, people you respect, people from whom you' d like to learn! There's a thought that "We become like the people with whom we relate", and I agree with that idea. Pick people who inspire you to be a better person, better developer, better businessperson, better musician. Keep the group small, and make sure your personalities work well together. Respect each other, and each other's skills and abilities. The weight of a project is nearly impossible to carry alone, so finding a co-producer, co-founder or partner is in my opinion very key to success.

I got lucky: I met a handful of talented, committed, brilliant musicians while we were all working with a complete lunatic. No, really, the guy was banana-nut bug$%#@ crazy. We cut the lunatic out of our lives and decided we'd all keep each other. We've been working together in music on and off for ten years now, and some of the best music production in independent music has sprung from our studios! Check out the works of Gypsy Soul and of Kevin Fisher to see what I mean. Roman Morykit of Gypsy Soul has been my producer and co-producer for years, and we work together extremely well. We all brought different knowledge and skills to the table - for example, while I taught everyone else computer skills and new project management techniques, they taught me music-production engineering skills, new work managment skills, and so on.

(I also found an excellent co-producer for the audio-effects library "Orchestrated Chaos". The director or a short film I'd scored proved to be another excellent choice for partnership in our sound-effects-for-television-productions project)

Early on, we all worked mostly from one studio, pooling our technical resources and our technical expertise, and most of what we learned is uncannily similar to agile software development. I'll talk more in detail about these in later posts. For you coders out there, isn't it interesting how some of these concepts overlap with "agile"practice, and some of the stuff the 37signals group talk about?


  • work harder than anyone else you know (which in our case was pretty easy): start early, end late. fear not the all-nighter, or the very-near-all-nighter.
  • use what ya got.
  • set boundaries (to what technologies will we limit ourselves?).*
  • be eager for change, be ready for change.
  • Descartes was right. But even so, don't forget about your instincts.
  • document everything.
  • don't be precious with what you've coded/recorded. Be prepared to toss it aside and move on: Hard Work doesn't always mean it's Cool or Good. And Cool doesn't guarantee it's also Valuable.**
  • tell nobody nuthin'. ("If you're gonna shoot, shoot. Don't talk")
  • work fast. quickly. fast. well, you know what I mean.
  • be flexible.
  • have a general project plan - a high-level design of what you want to do. When you end up doing might be different from your plan, but we had one notebook-page per song, and one notebook-page for the entire CD. Gypsy Soul had a stack of Cilette's lyrics to serve the same purpose, and even then they wrote some songs "on the fly" (see "be flexible").
  • take care of the people with whom you work.
  • no "ant-fucking". Splitting hairs. At some point, finish the task and move on. You can always go back, but it's preferable to go forward.
  • fear not failure. We learn by doing things the wrong way and then deducing the correct solution. If we already know how to do something, we're not learning, we're executing (this is not a manichaen dichotomy, by the way).
  • fear not execution. If you can do it, Do It.
* Too many limitations means no freedom. No limitations means no freedom.
**if you only knew how many songs we threw away after 18-hour sessions...


Some of the CDs made this way are here:

No comments:

Post a Comment