When you buy a washing machine, it's unlikely that it'll turn itself off half way through the first spin cycle - you'd be straight onto the retailer for a refund or replacement if it did. And when you plug in a new TV, you can be pretty confident that it won't change channel unless you instruct it to do so.
Sadly, though, music software isn't quite so predictable. In fact, most of us are pleasantly surprised when we install a new application or plug-in and it does work exactly as it should.
It's not entirely clear who coined the term 'bug' in relation to problems with software - it's often attributed to engineers who found a fried moth playing havoc with the circuitry of an old valve computer, but the usage of this word to denote malfunctions in electronic and mechanical devices predates this. What's more important, though, is that we establish precisely what bugs are.
Does not compute
Angus Baigent sums things up pretty succinctly: "A bug is when a part of the program is not working as intended. That can result in some kind of anomaly, which might take the form of a crash or some other problem."
This draws attention to the fact that some bugs are more serious than others, and that they can manifest themselves in all manner of ways
"Regarding categories of bugs, there are many classes," says Cakewalk CTO Noel Borthwick. "Some can be subtle, such as a glitch that doesn't properly redraw the screen. Others can be an undesirable interaction of one or more features, or can even be data- or project-related. System crashes can be more obvious, since they cause program execution to halt and, potentially, lead to loss of work (less serious these days, since our applications support crash recovery)."
"A customer can easily blame the software for any old problem - to be fair, we've all done it, haven't we?" Angus Baigent, Steinberg
This gives us an idea of how developers define bugs, but is it true to say that some of the niggles that seem to be caused by certain programs are actually due to conflicts elsewhere within the system?
"One of the things about software engineering that can be very difficult is reproducing a certain type of behaviour and isolating the cause," says Angus Baigent. "A customer can easily blame the software for any old problem - to be fair, we've all done it, haven't we? However, in an audio system with a DAW, audio card, plug-ins, customised hardware configuration, etc, there are myriad issues that can occur. One of the huge challenges in engineering a host application with the sheer scope and complexity of Cubase is that it forms the basis for an environment, and needs to work with many other technologies and products."
Friedemann Schautz, who takes responsibility for quality assurance and testing at Ableton, has a similar story to tell.
"Bugs that involve components from different vendors are typically harder to fix than bugs in a single component. But still they are bugs that can be addressed. The most crucial point is usually to get enough information about the issues so that they can be reproduced in a development environment."
It's certainly unreasonable to expect that developers test their software on every possible system configuration - it would be unfeasible, if not impossible - and this goes some way to explaining why bugs are, unfortunately, part and parcel of the computer music experience. What's more, as u-he's Urs Heckmann points out, programmers can only make educated guesses as to how their products will be used.
"It's often hard for a developer to foresee all the things that users do with the software," says Urs. "Sometimes one is baffled when, for instance, an artist wants to play a single note on a synthesiser for three days and complains that the LFO goes out of sync by a millisecond."
A testing time
All of this doesn't give developers a Get Out Of Jail Free card, though, as they have a responsibility to perform in-depth testing before asking anyone to pay for their software.
When a piece of software is in the early phases of development but is just about becoming a usable application - albeit a very rough and buggy one - it's said to be in the alpha stage. Testing at this point is usually handled in-house by the developers, and they strive to iron out as many issues as possible prior to the beta stage, where they hope to be refining rather than reworking the software.
"We go through rigorous alpha and beta cycles that flush out the most common and serious bugs long before the software is released to the public," explains Noel Borthwick. "However, due to the immense number of configurations and workflows, it's impossible to identify every single issue during this phase. We typically issue maintenance releases to tackle any severe issues detected after release."
"Public betas can be useful, but the success depends on the ability to handle the signal-to-noise ratio while dealing with a large beta group." Noel Borthwick, Cakewalk
It's not uncommon these days for the general public to be able to sign up to try out beta versions and report back any issues.
"Public betas can be useful," says Noel, "but the success depends on the ability to handle the signal-to-noise ratio while dealing with a large beta group. Also, due to the sensitive nature of the information shared, they can present some challenges for retail software companies who plan a product launch months before release."
Says Angus Baigent of Steinberg's approach: "Our Quality Assurance team tests the software or hardware product and report problems to the engineers, who try to analyse the problems and fix them, if possible. The key here is that the QA team are embedded within our development process, which is vital to offer the product quality in terms of stability and reliability."
An insolvable problem?
The internet has helped immeasurably when it comes to remedying bugs, as the vast majority of users can now access maintenance updates as and when they become available. Naturally, we all dream of a day when these updates are no longer necessary, but is it inevitable that music software will always contain bugs?
Angus Baigent believes that it is: "Regardless of how intensive your testing is and how experienced your QA engineers are, there will always be issues that only come up later on, because they turn up on a system configuration or in combination with other factors that you can't recreate beforehand."
"The number of issues gets lower the longer a particular version is out, but bug-fixing never really stops." Friedemann Schautz, Ableton
Noel Borthwick concurs, maintaining that "it's inevitable that any given software release will have issues that affect some users. What makes a difference is how efficiently a software company responds to and addresses these."
It's also worth emphasising that bug-fixing needs to be an ongoing process, as Ableton's Friedemann Schautz acknowledges. "We just recently released another bug-fix update for Live 7 (7.0.15), more than a year after the initial release of Live 7," he explains.
"The number of issues gets lower the longer a particular version is out, but bug-fixing never really stops."
In summary, it seems that bugs are simply a fact of life - ask any software engineer and they're bound to agree. As users, all we can do is trust that developers are doing their best to prevent and fix them.
Liked this? Then try:
10 things not to do when you're making music
Sign up for our free weekly newsletter
The free MusicRadar newsletter serves up the week's biggest artist and product news stories alongside exclusive tuition and gear reviews. Sign up here!
Follow MusicRadar on Twitter
Get instant updates and bonus content plus chat with the team. Start here!
