I’m a blogger. I’m supposed to be all about shiny, about scoops and exclusives, about fast-paced development. But even I’ve begun to wonder about the expectations some developers and users alike have about pace. And that doesn’t just apply to the vendors: it applies to writers and users, too.
One theme repeated again and again by developers around NAMM: let’s slow down. It’s not a new idea, but several recent developments make it doubly relevant.
Two hardware products revealed this week in functioning, working order had been separately accused of being vaporware, because they didn’t come out right away – perhaps an indication of the increasingly-compressed perception of time in technology. The Beat Kangz Beat Thang drum machine and Teenage Engineering OP-1 synth/sampler/instrument are now each nearing shipment. Now, I expressed some skepticism about each of these products, only because I tend to believe what ships — too many gorgeous prototypes have wound up unraveling along the difficult road to market. Yes, I even poked fun at the OP-1 for pushing my “awesomeness versus shippingness” continuum. But I’m not surprised that the gestation of these two tools has consumed some time. Frankly, it’s gotten to the point where I feel some relief when I hear about delays. Efficient design can mean faster development, so delays can be a bad thing. But if you really care about quality, sometimes you miss – or don’t set – deadlines.
On the software side, people are still talking about Ableton’s decision to freeze development to fix their software. It’d be a mistake to read too much into that: the 8.1 release of Live wasn’t up to their quality standards, and I’m convinced the underlying process will be improved so that future quality is better. But this goes beyond Ableton.
A correlation of this announcement is the realization that software doesn’t have to ship with bugs. Some tools in our industry simply ship too early. Beyond bugs, there are products that ship with important features missing, or incomplete realization of their ideas. There are products that should have gone through some revision that don’t. There are features that should be taken out and wind up getting left in. Some of this has to do with syncing up with distribution and marketing, but at least the rest of us can adjust our own expectations in regards to the parts of this process we do touch.
Gino Robair has a superb essay on this topic, spawned by the discussion here on CDM and what you readers have been saying:
Why Is This So Complicated? [Electronic Musician Robair Report Blog]
It’s worth reading his whole essay, which also responds to concerns that those of us in the press aren’t being fair and impartial in our reviews. But I want to highlight this passage, because it suggests that the industry can change:
Kirn notes that “all software has bugs.” Perhaps. But wouldn’t it be great if developers came clean and told us what the issues were when their products were released? Better still, wouldn’t it be a win-win situation if manufacturers didn’t make promises that they couldn’t keep about features, but only announced things that are fully functional, perhaps adding extra features in .x updates. Imagine if a developer announced and delivered a bulletproof version of their new audio app, then named five state-of-the-art features that would be added incrementally over the next few months in free updates to registered users (perhaps after they were bug-fixed using public betas).
In fact, as a certain developer noted, you shouldn’t even need a public beta to fix bugs. Adding features doesn’t have to mean adding bugs, because properly engineered, those features would work reliably from the start. Getting testers to find the bugs, or even producing those bugs in the first place, is a cost that should be avoided wherever possible. The goal of any engineering effort should be to stop bugs before they’re created, not test them after they’re created, or worst of all, ship them to customers. Prevention is the best medicine.
This sentence from Gino could be framed and hung on the wall of every software developer. (Actually, I say “developer,” when I should say “manager” – most developers are more than aware of this issue.)
Unfortunately, the industry is training an entire generation of users to wait for the first update before upgrading their apps.
That’s the crux of the problem: it’s one symptom of an epidemic of lowered expectations. Incidentally, when I said “all software has bugs,” I didn’t intend that as an excuse. (I actually got a couple of notes from prominent developers about that who passionately disagreed, partly because they have invested time to avoid just that!) Any software has the potential for failure under specific circumstances that may not be immediately discovered. In this case, though, the point of contention is really known bugs. And those don’t have to ship. Cosmetic issues often do ship, and that’s fine. But music software should be considered “mission-critical,” because to a musician, it is.
It’s known by different names, but most developers, regardless of industry, refer to certain issues as “known but shipping.” If that bug is something more serious, like a crash, it really isn’t okay.
By the way, if you think this is just about software, I think you’re mistaken. I’m biased toward the value of software, but I have to take issue with Gino Robair’s criticism of software’s disposability. I couldn’t agree more — on the software side, that is. I just happen to think it applies to hardware, too. As Gino notes:
Some announcements, however, just seem to pile sexy new features onto an older product while core issues remain unsolved.
Sounds to me like that applies to a lot of hardware electronics, too. And while traditional physical, acoustic instruments have extraordinary longevity – ask a 17th century viola da gamba – a lot of modern instruments, especially electronic ones, are designed to be as disposable as software upgrades. Also, at least a software update doesn’t impact the environment; electronic instruments produce toxins and consume energy in their construction, disposal, or both. (See Gino’s original editor’s note, which focuses on guitars. Gino would no doubt approve of the CDM readers still using their Commodore 64s.)
If we want this situation to change, all of us – not just vendors – will need to participate. All of us are to blame, not just developers. As users, we often ask for more – more features, more stuff – and we want it more quickly. There’s nothing wrong with that, necessarily. But we should also reward developers when they focus on improving quality, and some of the things you can’t see. Because I know we users care about those things, we should be willing to wait for upgrades if that wait pays off in quality, future-proofing, and stability. It’s not wrong to ask for more, but we should be prepared to wait if we want that “more” to actually work. Needless to say, it’s also important for users to invest wisely in software that has value, as some of these pressures are financial.
As writers and publishers, we sometimes aggravate the problem, as well. If we’re reviewing a product in a non-shipping version, we should identify it as such. We can all take the opportunity to review products not just when they’re new, but when they’ve been out for a while. (In fact, readers, if any of you want to help me with some “long-term” reviews of software — tools you know even better because you’ve used them for months or years – I’ll be making that a goal.) We also often look at the presence or absence of features in a vacuum, because that boils down nicely to “Pros” and “Cons” categories. It’s always a challenge, but we can try to go beyond that one dimension.
I don’t want to speak for any writer or publisher other than myself, or criticize any outlet or writer other than myself: this is directed primarily at me, because I’m the one I can control. So I’ll just say this: I’m ready to commit to spending more time with tools. That’s the way I work in my music, so that’s the way I would prefer to write about things. I still believe in getting information out there quickly, because on the Web, you get corrections, clarifications, and new knowledge more quickly as a result. But it’s possible to do that, and spend time on really getting deeper in topics. I also believe it’s important to focus on more than just “news,” which is especially tough – but also especially valuable – on a daily online site. I’ll take that as a personal challenge to myself — it’s New Year’s Resolution season, anyway.
Speed can be a wonderful thing. When I’m teaching, I regularly encourage students to sketch code in a day. Deadlines can be liberating. A number of creations I saw at NAMM got prototypes wrapped up in the days leading to NAMM, so the trade show itself can encourage the forward progress of development.
But some things are important enough that they take time. Sometimes, engineering a solid foundation means being patient now in order to save time later.
I can say, I’m seeing encouraging signs that a lot of music tech vendors are ready to get off the treadmill. I heard repeated again and again “we took longer with this, because then we could do it right.” I can’t imagine anyone complaining about that in the long run.
The food world has slow food, a movement that encourages sustainability, quality, health, local tradition, diversity, and taste. It isn’t just about the food: it’s about how that food is consumed and appreciated by the eater (read: user). I think we need “slow development” in hardware and software. All of the same issues are at stake. Even labor and environmental standards are issues, because music gear and computers, like agriculture, are now globalized and mass-produced.
Nor does this have to apply exclusively to the vendors at NAMM. All of us have projects, technological and musical, that could benefit from our own patience. It could be your new hardware controller, or your new album. The Internet age can be intimidating, as we see people making incredible progress and showing them off in just-uploaded YouTube videos. But each of us has a pace that’s appropriate for each process. Making things and making music should be an enjoyable process. If we’re slower than someone else because we’re learning, because we want to take extra time to work out the details that matter to us, we can savor that. We can give ourselves the time we deserve. That’s likely the first step to being patient with everyone else.
Ultimately, the choice comes down to us. It really is possible to derive new value from slowing down.
Read the rest here:
A New Theme in Music Technology: Slow Development
