I don't intend this to open a can of worms... I reckon bugs are enough but, having absolutely NO experience programming, I wonder... when people report bugs... are most of them really bugs? Does anyone have any sort of idea how many reported bugs are user error or hardware/driver related... and the question I had in mind when I started this post..
 
If something is an actual bug in the software, which I would define as some code that does not do what it is supposed to do, some function or feature that just does not work because of the software, in this case Sonar... that stipulated, WHY is a real "bug" so hard to fix? Why can't they just... well, fix it?
What up? I seriously do not know and I wonder... if they advertise it and it really is broken, why is it so hard to fix? .. or do they just not try to fix it or what? I guess this would require a subjective answer unless you are in the inner circle and really know.
 
I'll get the popcorn...
 
J

In the industry, we prefer to call them "features."

HTH.

The apocryphal story about bugs is that the term goes back to ENIAC, a room full of vacuum tubes and relays used to calculate artillery ballistics in WWII. A malfunction was traced to an electrocuted insect found in the works. Hence it was a hardware bug.

A software bug could be defined as any situation where the software fails to act as it was intended. It need not necessarily be present in every hardware system or software installation environment to qualify as a bug. So the software could be working fine on my computer and crashing yours, and if it was intended to run on systems which include both of our configurations, it is still a bug. 

Since it is impossible to know what exact systems, or simultaneously running software the application might encounter, it may not be possible to design the software so that it actually works as it was intended under all circumstances. The developer has to decide if it is worth the considerable time and money needed to re-code the software so that it works on your system as well as it does on mine. If there are few customers experiencing the problem, he will decide you are just not worth the trouble. Once he starts re-coding, he risks creating new problems (bugs) so that the fix that works on your system now breaks mine. 

Thanks... I was wondering about that, if changing something ran the risk of breaking something else. Thanks for the history lesson too, that is some cool info I would never have known!

Your answer explains a LOT.

J

I've sometimes wondered about this, too. It's easy to understand such "complicated" bugs that are set up dependable and thus often very unpredictable, because the variety of set ups is so immense. 
A stellar example of a real bug with a wing span of ten feet is the one in MC6 ( hide/unhide) discussed on the MC forum now. That must be the most inexcusable bug I've ever come across. It's really hard for me to understand it hasn't been fixed or at least reported to users exaggeratingly clearly. 

The bugs that are easy to fix generally get fixed quickly.

And it's difficult or impossible to know whether a bug is "easy" or "extremely difficult" to fix from an end user's perspective. You need to know what the code/program-architecture is. Sometimes something that end users think should be "easy" to fix requires not just code changes but architectural changes.

If the bug is in code that's reused all over the place or interrelated with other stuff then you will need to do boatloads of testing to make sure you don't screw up something else. And fix it if you did.

And if the problem involves interaction with other code not under your control (like OS .dll's or audio/video/printer drivers or 3rd party plugins or...), which may or may not act the way it's supposed to (or the way you think it's supposed to - based on your interpretation of documentation that may be open to interpretation - assuming it's not just blatantly inaccurate in the first place).

And for something like a DAW, performance considerations are also paramount - you don't want to reduce performance for everyone to fix a bug that affects a limited number of users.


Note that none of this should be taken as an excuse for things that should be fixed not getting fixed.

Sometimes the bigger problem is in not having and/or allocating enough resources to fixing things that need to be fixed.

jbow,
 
You got a nice answer from slartabartfast to some of your questions. I'll try to deal with some of the others.
 
Is it really a bug, or a user error?
 
In a lot of companies, support people go through these reports and try to reproduce them. For this, it's really helpful for the user to describe the conditions and steps in great deal. It's hard for support to take a user seriously without this detail. I wouldn't want to guess the ratio or bugs to user errors in Cakewalk's case.
 
Isn't it easy to fix bugs?
 
In a few cases, a bug is just  due to a typo or small mistake in the code. Those mistakes should be easy to fix, but there still has to be some testing done afterward. A few bugs start at the design stage. Those require a lot of planning to fix and might be just too risky to fix, because they might break things for other users.
 
Other comments.
 
For most projects, software testers write test scripts, scenarios that can be repeated at various points in development. If the script fails, the testers report defects. After the programmers fix the defects, the testers rerun the scripts.
 
I reckon that Cakewalk programmers and testers have a harder job than most, since the product is so big and complex, can be used in so many ways, and work with so many hardware and software configurations. Even if they have an army of beta testers, problems are bound to slip through and be discovered by users.
 
Users can contribute to quality by reporting their defects with supporting details: logs, screen shots, descriptions of hardware and software environments, and exact detailed steps that led up to the problem. Sometimes a simple statement of the consequences of the problem may be helpful, but insults, expressions of anger, and exaggerations are counterproductive.
 
Mitch I.
 
 

Software is complex. I don't mean complex like an internal-combustion engine, I mean complex like the stock market. Complex beyond imagination. Paradoxically, though, writing software isn't all that complex. You don't have to be a genius like bapu! (Although he's getting out of the bit-flipping business in another week or so. That is genius.)


Consider the basic branch instruction.  A typical branch instruction looks at a number and decides if it's zero or not. If it is, execution jumps to a new location. If it's not, execution proceeds linearly. Very simple, and the crux of what CPUs do. CPUs can do basically two things: add two numbers, and determine if a given number is zero, less than zero, or greater than zero. That's pretty much all a CPU can do. And it's certainly not complex.


But as soon as you insert one of these decision points (a branch instruction) into a program, you have now doubled the number of possible paths of execution. And every subsequent decision point doubles that number again. Solitaire might have 50,000 of them. SONAR has literally millions. If you count external libraries, it's hundreds of millions. To actually try out every possible execution path would take thousands of years.


Software is therefore complex by nature. And this is why achieving defect-free software is an impossible goal. Yeah, somebody will come along and say they wrote software for guided missiles or nuclear reactors and it had to be flawless, and it was. But that's actually unlikely. Given enough time and resources (e.g. a Department of Defense-sized budget) you can reduce bugs until they're too trivial to bother with. But then you'd better not touch it! 'Cause then you'll have to start the validation process all over again.


In the commercial world, though, you don't have 10 or 20 years to develop an application and then not touch it again for another decade, like they do in the nuclear industry. With consumer software, development is on-going, never stops. When X1 was released, chances are CW was already at work on X3.

bitflipper


Consider the basic branch instruction.  A typical branch instruction looks at a number and decides if it's zero or not. If it is, execution jumps to a new location. If it's not, execution proceeds linearly. Very simple, and the crux of what CPUs do. CPUs can do basically two things: add two numbers, and determine if a given number is zero, less than zero, or greater than zero. That's pretty much all a CPU can do. And it's certainly not complex.


But as soon as you insert one of these decision points (a branch instruction) into a program, you have now doubled the number of possible paths of execution. And every subsequent decision point doubles that number again. Solitaire might have 50,000 of them. SONAR has literally millions. If you count external libraries, it's hundreds of millions. To actually try out every possible execution path would take thousands of years. 

However, the above scenario (now long dead) was easy compared with today's programming which is event based meaning, instead of a program starting at the top and working "top down" in a very linear fashion, you now have a virtually unpredictable path depending on the whim of the user and where they decide to click, drag, mouse-over, left-click, right-click, etc.!  And each path can be different based on the conditions under which said action took place.  As if THAT wasn't bad enough, almost everyone now has multiple processors so the program's work is getting parcelled out for pseudo (or real) parallel processing.  Now you have to keep track of the interactions between multiple portions of buggy code.
 
Oh yeah, and it GETS WORSE!  Most programs can be run with multiple iterations so multiply the you-know-what out of the above.  Actually, it's quite amazing that anything works as well as it does (there are some reasons why - but those aren't as much fun to talk about ).
 
I wonder how many people even know that four bits is called a "nibble" any more?

I have very limited experience coding (C, C++, Python and Java) and even in the relatively tiny programs that I've written, I know how hard it is to track down a bug. You can be staring at the code for hours thinking "well this does this...OK.... and then this value gets passed here....fine....and then it makes this call....and this does that and that does this....OK...SO WHY IN THE HELL ISN'T IT WORKING?"

And you sit there tearing your hair out and then all of a sudden it hits you....one tiny value or dependency that seemed so insignificant but which set off a chain reaction into a full blown bug. It really gave me respect for those who can write such huge and complicated apps like Sonar, and understand how everything works. 

But sometimes you'll hear a response from the manufacturer which really makes you wonder just how in the hell this code was designed. An example was when I reported a bug in which automation of the ProChannel FX Chain on/off button only works when the ProChannel in question is open and visible on the screen. Someone from Cakewalk said that it wasn't a bug, more of a "design flaw," and that fixing it would break such a large part of the code that they considered it not worth fixing. I mean when I really thought about that, I couldn't help but think that something in the fundamental architecture of the ProChannel code is not quite right.