Serious question re: bugs in software...

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

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. 

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. 

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.
 
 

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?

craigb

 
I wonder how many people even know that four bits is called a "nibble" any more?

Ooo I do! Me! Me! I read Charle's Petzold's "Code" not so long ago and was enlightened with this and many other "nibbles" of archaic computer terminology. Great book. 

I don't believe any of the excuses about hundreds of millions of possible things to test for. It's a distraction. It's Wizard of Oz smoke and mirror type stuff.

Software can work more perfectly than stuff manufactured from dirt and goo.

Software, like a DAW, only has to do a few things. It doesn't actually do hundreds of millions of things.

We all pretty much want a DAW to be a DAW.

So when an EFX channel strip flickers on and off while we are playing back... that's a bug. Fix it or swim for shore.

When the Loop record function cuts off tiny snippets of audio, leaving a gap and throwing it away for 10 versions in a row. That's a bug. Fix it or end up with frustrated end users.

When the stereo inter leave button swaps modes in the back ground versions, every time you hit "record", well... that was a bug often times excused as "intended misbehavior". It got fixed after years of petitioning. Finally, one particular guy at DAWquarters listened carefully and instead of offering excuses he took the time to understand the nature of the complaint and by the next update that pernicious and frustrating decade old bug was fixed! Yeah man.

I don't buy any of the excuses.

Software with a bunch of bugs reflects the practical circumstances of the company that produces it.



Internal Combustion engines? Now, that's some complex stuff. :-)



:-)