Give ‘em what they want

Last night, I was sitting in bed reading the latest issue of TapeOp (music recording magazine). I used to be moderately involved in recording music, but these days I mostly just follow the trends and try to stay sharp. TapeOp has a lot of interviews with recording engineers and producers, and it’s great to hear what their thoughts were when they made some of their more famous recordings.

I feel sort of stupid that it took me until last night to notice (yet another)  interesting parallel with music and software. Recording is mostly a waterfall process. You record, then you mix, then you master. Some iteration is possible – you can record one song or a whole album before you mix – but most of the time, you finish recording, then you mix. When you’re dong mixing, you master. What’s interesting, is that there are a massive number of opinions on how to do each of these activities. Which mics are “best”? What rooms are best for recording a jazz combo? Do you record rock guitars with mics perpendicular, or at an offset? When should you use multiple mics? Where do you add eq? How loud do you make the vocals.

Then, there’s mastering – which in my opinion is awful on almost every pop or rock recording made in the last 10 years. Mastering (IMO) ruined the latest Metallica and Springsteen albums (and probably many others that I haven’t bothered listening to).

Whatever I think, the albums sold millions, and were (AFAIK, critically acclaimed). You know why – because despite the mastering – despite the fact they may have not used the best microphones or mic placements possible, it’s what the customer wanted. You can take the most well-rehearsed band in the world – use top notch equipment and fantastic production to recreate their sound exactly. You can add just the right punch and pop and remove any harshness and engineer the best recording ever.

But it doesn’t mean it will sell. Customers want something different, and if you don’t give them what you want, all you have is something that you are proud of, and not something that puts dinner on the table. Along the same lines, you can’t ignore the technical part of the process. Engineering quality still makes a difference, as long as you’re doing the right thing.

Same thing as my current day job.

Similar Posts

  • Tester DNA

    In HWTSAM, we (Ken, actually) talked a bit about tester DNA – that bit of mental goo that makes some people better (or at least more prone to being) testers. As I’ve been talking to (potential) testers lately, I’ve had a chance to dwell on this a bit more. What is it that makes a…

  • Riffing on the Quadrants

    In 2003, Brian Marick introduced the concept of “Agile Quadrants” to describe the scope of testing[1] (later expanded on by Lisa Crispin and Janet Gregory[2]). Several people (including me) have expanded and elaborated on the quadrants to describe the scope and activities of testing. Here’s a version of the testing quadrants. One challenge I’ve seen…

  • In search of code quality

    I’ve been thinking recently about what ‘code quality’ and what the phrase means. How does someone identify the difference between low quality code and high quality code (or medium quality code)? In my quest for knowledge, I discovered a few interesting things. I discovered the Spinellis book, Code Quality: The Open Source Perspective. I haven’t…

  • Learning to learn

    As I write this, I’m waiting (literally, waiting on hold) to give a webinar for Swiss Testing Night. It’s a twenty minute presentation – which I love (see my last post for another twenty minute presentation from me. I would love to see a test conference filled with nothing but 20-30 minute presentations someday (and…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.