# What is a "bug" ?



## Ashermusic (Apr 9, 2010)

What is a "bug" ?

Something that has become ubiquitous on the internet fora is really starting to, well, bug me, and that is the indiscriminate and to my mind inaccurate use of the term "bug." It also bugs, I suspect, a lot of developers.

The dictionary defines "bug" broadly as "an error in a computer program or system." This is now renders it a meaningless word as anyone who has any issue on their system with a software app can describe it as a bug in the software. 

To me, a bug in software is something that will happen to all, most, or at the least many users who use it. If it only happens to a handful of people using an app with a specific computer, OS, or combo of hardware/plugins, then it is not a bug, it is a system specific issue.

Here is an example of what I would call a bug. Logic used to have a feature called "wait for note" where recording would begin with the striking of your keyboard controller. At some point, this stopped working., nonetheless it was still listed as an option. Eventually, Apple acknowledged that it was indeed not working and that they probably would not fix it so they just removed it.

THAT was clearly a bug. It happened to 100% of users 100% of the time. Conversely I will read something like, " I am running Logic Pro version whatever on OSX whatever with such and such audio interface and if use plugins A, B, and C, all of a sudden Logic gets really slow and gives me error messages. It is really buggy software."

Someone will respond and say, "Gee I am using almost the identical stuff and I am not having this."

THAT is clearly NOT a bug in my mind but a system specific issue.

Whaddya think?


----------



## bryla (Apr 9, 2010)

Yes! I also hate to see topics named: beware of X software's bug, when it seems obvious that it is system specific. I even wish moderators would rename such topics - we do at a Danish soundforum anyway.


----------



## Dynamitec (Apr 9, 2010)

Hi Jay,

I think your conclusion isn't fully correct. But it's not completely wrong either. 
I think it's really not an easy question. 

Why can system specific issues also happen?
1) Sloppy programming
2) Sloppy testing (not finding issues mentioned in 1)
3) 1 & 2 happening on OS/driver side maybe introduced in an update, so the developer might not be responsible at all (something I wouldn't call a bug in that case)
4) In plugin cases: changes of the host, which might lead to problems with plugins. A case plugin developers sometimes can't do anything about either.

But in my opinion 1 & 2 are still bugs. A bug which happens for 50% of all users, is still a 100% problem for those 50%. And as a user I don't care if it's a system specific issue or not.

I've bough BIAS Repli-Q years ago when it came out. It was supposed to work in Wavelab 6 (mentioned as tested VST host on the webpage), but it never work (until the latest update to be fair). So for me it was 100% wasted money that time, while other users not using WaveLab had no problem at all.

Bug or system specific issue?


----------



## Ashermusic (Apr 9, 2010)

Dynamitec @ Fri Apr 09 said:


> Hi Jay,
> 
> I think your conclusion isn't fully correct. But it's not completely wrong either.
> I think it's really not an easy question.
> ...



Thanks for weighing in, since you are a developer it is good to get your perspective.

As for sloppy programming/sloppy testing: as a guy who has beta tested for a lot of companies I will say the following:
In a plugin, it is one thing as it is more limited, but in a long running DAW there are a gazillion lines of code that changing can have unforseeable consequences and no matter how good the testers are, there are so many different models of computer, versions of OS, audio interface drivers, other plugins, that there is simply no way to release a new version and not have issues for some users. And unfortunately, then you get a bunch of "why is this program so $%^& buggy" when to my mind, once again, they may be only system specific issues.

Even if it is a 100% problem for that user, that still does not necessarily make it a bug. If it happens to 50% of users, sure, I would call it a bug.

What I am arguing for here is a little semantic self-discipline. But then, self-discipline is no longer a very popular concept, is it?


----------



## Dynamitec (Apr 9, 2010)

Oh, no problem to 100% agree on your last sentence! Definitely it's a much better way to write "I have a problem with..." instead of "Program X has a bug...". 

But in my opinion, it's still a bug if a software doesn't work on some systems. If the developer is responsible or the OS developer, the driver developer or the host developer it's a different question.

An interesting quote on how NASA is developing software:


> But how much work the software does is not what makes it remarkable. What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.



http://blogs.howstuffworks.com/2009/05/ ... computers/


----------



## JohnG (Apr 9, 2010)

I like the impetus behind your original post, Jay. When 10,000 users are working fine but a small subset with a particular configuration has a problem, it's not exactly a "bug."

Then there are some who, having encountered a problem, refuse to update, saying, "that company stinks and I'm not going to try to update their buggy software."

Which isn't too productive.


----------



## Dynamitec (Apr 9, 2010)

The way the discussion is going here, the question shouldn't be "What is a bug" but rather "How should I behave if I might discover something that isn't correctly working on my system". 

Don't get me wrong: especially as a developer it hurts to see guys writing that something isn't working, while it already had been fixed but they never installed an updated at all. So I totally agree on Jays intention in his original post.

But I have a different opinion on what I consider a bug that you guys seem to have.


----------



## Olias (Apr 9, 2010)

Bugs often have to do with incorrect or lacking handling of unforeseen circumstances. Once the circumstances can include plugins, etc, the permutations of circumstances explode. But regardless of that, software that doesn't handle some condition and crashes has a bug. If it puts up a message like "hey, I can't do that" it's not a bug. It might be incomplete, but it's not a bug.

But with these complex systems we have, it's also hard to know which component has the bug. Witness the VEPro/PLAY flap. If VEPro isn't going to host PLAY, that's fine, but if it does it by not showing the UI but thinking everything is fine, or by crashing, or whatever it does, then that's a bug in VE Pro. Even if the reason it can't host PLAY has to do with a problem in PLAY, VE Pro should handle that failure gracefully. (imho, anyway)


----------



## Ashermusic (Apr 9, 2010)

Are all incompatibilities necessarily a "bug' on someone's part?


----------



## Olias (Apr 9, 2010)

No, that's not what I meant (assuming you're asking me). Incompatibilities aren't necessarily bugs. Not handling incompatibilities in some graceful way is a bug.

Incompatibilities aren't necessarily bugs in any particular piece of software. For example, in the VEPro vs PLAY situation, which software has the "bug"? If PLAY is built in a way that doesn't allow it to work in VE Pro, then that might be a bug. But if it can't work in VE Pro because of something in VE Pro, then maybe that's the bug. And in either case, if VE Pro crashes when you load a PLAY instrument, then VE Pro has a bug. (It could, at least, say "sorry, you can't load PLAY, or I'll crash... neener neener neener...")


----------



## Ashermusic (Apr 9, 2010)

On Gearslutz a guy wrote: "A more formal definition is 'behavior or results that differ from the developer's written specification'."

I like this one!


----------



## kdm (Apr 9, 2010)

bryla @ Fri Apr 09 said:


> Yes! I also hate to see topics named: beware of X software's bug, when it seems obvious that it is system specific.



A lot of bugs are system- and/or application dependent. i.e. it will only occur under certain conditions that include how the application is being used, sequence of events, and unique circumstances like other software on the system, ram, memory usage of other applications at the time, etc. 

Often, bugs are too easily dismissed by users and developers as "system problems" and linger for months or even years.... I can name several I found myself that were clearly not system-problems, but were only trigger under specific system configurations (not just mine). Imho, this is one reason there seems to be a declining standard of acceptability in terms of software stability. 

The worst bugs are in fact the ones that only occur 1% of the time, and yes, they are real. In hardware, issues like heat, grounding, RF interference and introduce problems that are very hard to track back to the source. The same is true of software, esp. when it interacts with a complex OS, audio drivers, other applications using memory, etc. Having 10,000 people say it works says nothing about the existence of a bug. It only suggests that 10,000 people haven't run into the problem - it could still go either way.

That's my .02 as a former developer.


----------



## C M Dess (Apr 9, 2010)

A bug or glitch is not that "serious".

It's used casually, it generally accepted that most software has bugs or "kinks". The term comes from debugging it seems. A "buggy program" however is a stain on the integrity of the program. Sometimes we have to use a buggy program because it is a standard such as Microsoft Word or Adobe Acrobat Distiller. All of us users have our own threshold to determine how many bugs are tolerable and whether or not we have enough faith in the developer to stick with the program or seek an alternative. So bugs are not a deal breaker necessarily. When people mention that certain software has bugs, it doesn't hinder my decision to pursue the product because I know I will seek ways to work around the bugs as they come.

Now the issue of *unexpected* incompatibility is different because it is an oversight of the developer in some cases. In this example it's important that the developer be advised to warn future customers of the situation.

http://en.wikipedia.org/wiki/Software_bug


----------



## C M Dess (Apr 9, 2010)

Funny, I was just thinking about my own personal thoughts on it, but it looks like I was very close to reality for once!

"A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports detailing bugs in a program are commonly known as bug reports, fault reports, problem reports, trouble reports, change requests, and so forth."

Interesting:
"US Department of Commerce' National Institute of Standards and Technology concluded that software bugs, or errors, are so prevalent and so detrimental that they cost the US economy an estimated $59 billion annually, or about 0.6 percent of the gross domestic product."


----------



## C M Dess (Apr 9, 2010)

In the case of VE Pro not working well with Play, this is incompatibility for the time being and not a bug.


----------



## Dynamitec (Apr 9, 2010)

Where do you know this from? It could also be, that there are bugs which cause the incompatibility.


----------



## ComposerDude (Apr 9, 2010)

...


----------



## C M Dess (Apr 9, 2010)

Dynamitec @ Fri Apr 09 said:


> Where do you know this from? It could also be, that there are bugs which cause the incompatibility.



I know what you mean, but in this case it's in a more sever stage, unsupported. If it isn't supported, there can be a lot of software conflicts so it isn't fair to try to gauge the number of bugs until they officially support it and run through all the debugging stages. Bug is used after software has been officially specified to function in a certain way but doesn't. 

The point is that one needs to be able to differentiate between buggy (already developed but has errors) and unsupported (incompatible) and has conflicts which can mean it's still in development or will be unsupported indefinitely.

http://vsl.co.at/en/211/497/1685/1693/1742/1369.htm


----------



## bryla (Apr 9, 2010)

Ashermusic @ Fri Apr 09 said:


> On Gearslutz a guy wrote: "A more formal definition is 'behavior or results that differ from the developer's written specification'."
> 
> I like this one!


So a dev can write:
"The DAW always crashes during bouncing. You'll get used to it, but don't think you'll be able to bounce' and it won't be a bug 

kdm: No a bug is related to the app. If Logic does something that differ from the specification.


----------



## kdm (Apr 9, 2010)

bryla @ Fri Apr 09 said:


> kdm: No a bug is related to the app. If Logic does something that differ from the specification.



Not true. However, in this case I was using "app" to infer the application of the software - usage, not specifically Logic, Nuendo, etc.

But regardless, bugs can occur only within one application (i.e. a plugin works in one app but not another) - and this can happen due to a number of factors, not just deviation from specs. In the case of plugin and host application, if both have an error that deviates from spec, that can surface with that application, but the plugin may not exhibit any problems in another application. 

Also, don't assume that specs cover all conditions accurately, or that all developers follow them rigidly - they don't. I've attended IEEE meetings and been in spec reviews - specs are a developing concept that is likely to change as products develop. Only some aspects can be "set in stone" before the first line of code is written. 

I've seen devs blame the VST spec for bugs that other similar plugins don't exhibit (such as EQs, of which there isn't much deviation in how one can be implemented beyond the actual dsp, GUI and automation parameters). In the end, it was a bug in their plugin simply for not accounting for weak areas of the spec (error checking).


----------



## Nick Batzdorf (Apr 9, 2010)

A bug is anything that goes wrong with Pedro Camacho's rig.


----------



## nikolas (Apr 9, 2010)

Ah. Darnit! You come and define what a "bug" is. And I was just about to go to the Sibelius forum and start taling trash about Finale 2009! How it will crash after some time of working on it on Windows 7 Ultimate 64-bit! :D Regardless if Finale 2009 was created prior to the release of even any beta of Win 7, thus if obviously isn't fully compatible! :D LOL!

No, but really, it does depend on the situation, and the above example about Finale is certainly NOT a bug. However anything interfearing (yup, "fear") with your work that was not supposed to IS a bug!


----------



## drasticmeasures (Apr 16, 2010)

behavior or results that differ from the END USER'S performed specification


----------



## Nick Batzdorf (Apr 16, 2010)

Seriously, I say a bug is something that doesn't work properly, and one that's unique to certain system configurations is still a bug. And conflict on a system that's within the developer's spec is a bug.

The point at which the question becomes more than semantic is if someone shouts to the whole fricking internet that a mythical upgraded product - let's call it Triple Wasp - is "still buggy as hell" and therefore nobody should buy it. That's a far cry from "I'm frustrated because I'm still having problems with Triple Wasp on my rig."


----------



## Mahal (Apr 16, 2010)

There are examples where a behavior of a piece of software that person A consideres to be a bug is considered a valued feature by person B.

I can't provide a good example in the area of music software at the moment, but Microsoft Word comes to mind (a usual suspect when talking about software failure). I remember a coworker who put non-printable characters into word docs because they were printed out as empty squares and he liked these squares. From the software engineering point of view, these squares were a bug. But when Microsoft finally fixed it, my coworker was upset because from his point of view, MS had removed a great feature.


----------

