Thank you to our Sponsors
Bugs are faults. A working item has no bugs.
Martin
All software has bugs.
But it doesn't have to - and not to the point that the product doesn't do the basics, - this is not a bug it is a defective productive, knowingly sold by the manufacturer .............. criminal!
It does have to I’m afraid Puncher. No one has yet found a way to develop software that is bug free.I agree completely that the nature of the bugs can render a product useless or frustrating but that wasn’t my point. I was simply commenting on a statement that said a working item has no software bugs because that statement is incorrect.But it doesn't have to - and not to the point that the product doesn't do the basics, - this is not a bug it is a defective productive, knowingly sold by the manufacturer .............. criminal! Ban boring signatures!
But it doesn't have to - and not to the point that the product doesn't do the basics, - this is not a bug it is a defective productive, knowingly sold by the manufacturer .............. criminal!
Ban boring signatures!
It does have to I’m afraid Puncher. No one has yet found a way to develop software that is bug free.
I agree completely that the nature of the bugs can render a product useless or frustrating but that wasn’t my point. I was simply commenting on a statement that said a working item has no software bugs because that statement is incorrect.
Really? In my career we delivered a lot of products that were heavily dependent on software that didn't get any updates or fixes until the customer wanted to add additional capabilities, or tweak the performance (e.g. adjust autopilot gains as the drag of the bird was measured wrong). Of course we did very extensive testing, but then the devices we built were far, far more complex than a pair of headphones or a BlueTooth speaker.
The purchaser should not need to upgrade software "out of the box", the dealer should do that prior to sale. These are expensive headphones and should work on receipt.
I accept all of that Jeff. Extensive testing will identify bugs and then all known bugs can be addressed or worked around if one is so inclined. But I’ll guarantee you bugs will remain that have not been discovered. They may not impact on what it is you want the software to do if your testing is good but they will be there. They always are. My point is a pure one about software development, all code has bugs. I am not saying for one moment that stuff shouldn’t work properly. If you are still in touch with the guys who did the development for you ask them if they could guarantee their code to be bug free (not whether they have fixed all the bugs they have found but whether they guarantee they have found all the bugs). I’ll bet you a beer I know their answer. 🍺Really? In my career we delivered a lot of products that were heavily dependent on software that didn't get any updates or fixes until the customer wanted to add additional capabilities, or tweak the performance (e.g. adjust autopilot gains as the drag of the bird was measured wrong). Of course we did very extensive testing, but then the devices we built were far, far more complex than a pair of headphones or a BlueTooth speaker. Jeff Beovirus victim, it's gotten to be too much to list!
Yes it is in the online manual accessed from Beoplay appI hope this is in the manual! Ban boring signatures!
Really? In my career we delivered a lot of products that were heavily dependent on software that didn't get any updates or fixes until the customer wanted to add additional capabilities, or tweak the performance (e.g. adjust autopilot gains as the drag of the bird was measured wrong). Of course we did very extensive testing, but then the devices we built were far, far more complex than a pair of headphones or a BlueTooth speaker.
Jeff
Beovirus victim, it's gotten to be too much to list!
I accept all of that Jeff. Extensive testing will identify bugs and then all known bugs can be addressed or worked around if one is so inclined. But I’ll guarantee you bugs will remain that have not been discovered. They may not impact on what it is you want the software to do if your testing is good but they will be there. They always are.
My point is a pure one about software development, all code has bugs. I am not saying for one moment that stuff shouldn’t work properly.
If you are still in touch with the guys who did the development for you ask them if they could guarantee their code to be bug free (not whether they have fixed all the bugs they have found but whether they guarantee they have found all the bugs). I’ll bet you a beer I know their answer. 🍺
Thank you Captain Pedantic!😎 If a "bug" does not affect the operation of the machine during it's normal and even extreme performance boundaries, is it a bug? For example, if after 10 minutes of flight there's a "bug" in the autopilot that causes a buffer overflow that crashes the computer to occur, when the maximum flight duration between missile and target is about 90 seconds, is that a bug?
The simple fact is that far to many companies, especially B&O, do not perform adequate testing, either originally or for updates, and it's shocking. It IS possible to deliver code that is for all practical purposes bug free, that does not immediately need updates or patches. Whether there's a pedantic bug somewhere in there that is undetectable calls into question just what you are calling a bug, semantically as well as practically. One system we pushed out went 5 years without a s/w update, despite being in nearly constant combat use, until such time as additional capability was added to expand the mission capabilities. No s/w related issues were ever discovered in the field with that release, although a couple of hardware issues were addressed, such as power supply transistors which would occasionally blow.
Yes.Thank you Captain Pedantic! If a "bug" does not affect the operation of the machine during it's normal and even extreme performance boundaries, is it a bug? For example, if after 10 minutes of flight there's a "bug" in the autopilot that causes a buffer overflow that crashes the computer to occur, when the maximum flight duration between missile and target is about 90 seconds, is that a bug?
Thank you Captain Pedantic! If a "bug" does not affect the operation of the machine during it's normal and even extreme performance boundaries, is it a bug? For example, if after 10 minutes of flight there's a "bug" in the autopilot that causes a buffer overflow that crashes the computer to occur, when the maximum flight duration between missile and target is about 90 seconds, is that a bug?
Yes.
I would say you're incorrect. The textbook definition of a software bug is:
A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.
If the "bug" as you call it is incapable of being manifested during the normal operation of the system, indeed in this instance beyond the life of the system, it never meets the definition of a bug.
How much s/w development work have you done? If you have, what standards or definitions does your technical realm use that's different than my aerospace/DoD one? I am certain NATO is similar to identical to our DoD standards, as we did develop dual use systems for Europe and the US.
As it is, you're getting hung up on semantics as a reason to be pedantic about it. Now if you said no s/w was perfect, I could easily agree with that, as it includes both issues that will never been seen as above and also inartfully or inefficiently coded algorithms.
You must be logged in as a BeoWorld member to post replies to forum threads.
Register to access the forums, reference material, and exclusive member benefits — including our monthly prize draw.
Become a Member