Lessons from a Former Life #3

By Ryan McClead July 30, 2018
Capture d’écran de Musescore 1.2 utilisé sous KDE

When I first moved to NY, I wrote all my music out by hand.  I’d buy staff paper with the lines pre-drawn, and I’d fill in clefs, time signatures, key signatures, measures, notes, etc.  This worked great, except that it was extremely time consuming, labor intensive, and my music notation was almost as bad as my handwriting, so even I had trouble reading it.  Thankfully, at about the same time, affordable music notation programs were coming on the market and surprise surprise, I was an early adopter.  These programs connected a PC or Mac to a keyboard using the Musical Instrument Digital Interface (MIDI) and frankly, there were more than a few bugs in the system.

It was not uncommon for me to spend all day, playing music into the computer, reformatting, spacing it just right, and meticulously editing lyrics, only to have the program crash right before I took a break for dinner.  Just like working in word processors of the time, I learned to save my work often, but unlike word processors, saving work was not necessarily an indication that I could actually retrieve my work later. The midi files would often become corrupted at which point, none of my work was salvageable.

The first few tens of times this happened, I was completely dejected. All of my time and effort was wasted.  My brilliant compositions were lost forever, sacrificed to the fickle and wicked gods of MIDI.  I cursed the software, the computer, the keyboard, and myself for being such a lazy composer.  Mozart never had notation software, and he seemed to do okay.  Every time this happened I would sulk for a while, have stiff drink or two, and start all over again the next day.

Over time I began to notice a pattern emerging.  The work that took me all day to do the day before, only took half a day to complete the second time around, and in the process of recreating my earlier work, I invariably streamlined, simplified, and generally created something markedly better than I had done the day before.  This was universal.  I never once ended up with a worse piece of music having lost my original to MIDI corruption. Over time I came to relish in these opportunities.  I would rock up to dinner with friends, beaming with satisfaction and when they asked why I was so happy, I’d say “I lost all the music I wrote today to corrupt MIDI files.”  Needless to say, they thought I was nuts, but in my experience lost to corruption meant that I was going to create something even better the next day.

In time the notation software got better, the OSes improved, MIDI technology became more reliable and I rarely lost notation to corruption, but by then I had learned my lesson.  To the consternation of my collaborators, I would sometimes finish many days of work on a piece of music and then promptly delete it.  I typically did this when I really liked the music but just knew it could be better than it was.

Lesson from a Former Life #3:  Throwing it all out and starting over is actually a valuable technique for cleaning out the cruft.   

Cruft is the useless crap that builds up in any creative endeavor as you iterate.  It’s as much a part of legal technology as it is music composition. Invariably you run into some difficulties early on and have to find kludgy work-arounds to get where you think you’re going.  At the time these solutions may seem inspired and brilliant, but often when you look back from a completed product, they will stand out as needless diversions, fruitless branches, and dead ends that never quite developed into anything worthwhile.  It’s hard to intentionally excise these elements from your work after the fact.  One section inexorably leads to the next.  You can’t just take out a bit here and a bit there and try to keep the coherence of the whole. BUT, you can start over.  And as daunting as that sounds, you’re not starting from scratch.  You’ve already done this once and now you have a clearer idea of what the end product should be, what the pitfalls are along the way, and which twists and turns you should avoid.  Armed with the knowledge of previous experience, the second time through is always faster and always ends in a better, cleaner, and more polished product.

It’s natural to want to keep everything you’ve done.  You want to show your bosses all of the great work you did.  You want your employees to see all of their work in a final product.  You want to be recognized for the genius solutions you came up with along the way, whether they are relevant to the task at hand or not. But a lot of work that goes into innovation solutions results in cruft. You need to clean it out occasionally and you need to be willing to let it go.  Technology, unfortunately, is no longer helpful in this regard.  Everything is cloud-based.  Every back-up’s back-up is backed-up. It’s nearly impossible to lose work unintentionally.  So, sometimes you need to intentionally lose your work. Even if it’s only a hypothetical exercise.

As you’re approaching the finish line of a project, ask yourself or your team a few questions:

If we were to start this project today, knowing what we now know, how would we do it differently?

What would we not do?

What would we do sooner?

How could we further simplify our solution even at this late date?

How long would it take us to do this project from scratch if we suddenly lost all of our existing work?

And maybe more importantly, would we bother starting over if we lost our work?

If the answer to the last question is no, then just stop. Make the case for why this project should end and go on to the next.  If the answer is yes, and you have time to start over and still deliver on time, then I would encourage you to accidentally unplug a server or forget a password and do it all over again.  The resulting solution will be better than whatever you have done already.  I promise.