What is considered BUGS by Development groups
Posted: Fri Oct 03, 2008 7:37 pm
I started this as to try to help a little as to what are BUGS???and what are NOT.
It is an attempt to get us all on the same page when communicating with each other, especially with Korg Development.
Based on my significant experience in hardware desgn and service, firmware design and trouble shooting ...and of course operating system tech. service and debug I offer some things to consider about BUGS.
Bugs are:
A) Documented 'functions' in a machine that do not work as described
B) Things that happen in a machine that are not supposed to while doing supported 'functions'. In other words unexpected behavior.
C) Instability in operation in general...Freezes, crashes, slow operations when they should be fast, non responsiveness to buttons/controls, etc.
D) Things (sounds for example) that have undesireable short commings of lower quality than expected or advertised is in my opinion are bugs...like some of the SAX (and other) sound problems in the PA today. This one may be borderlne as to being a bug? Maybe just more of a quality issue?
Bugs can be in the hardware (like keys that don't respond properly, intermittent switches etc) Firmware (for practical purposes is the same as hardware except it is software that directly determines hardware function) and software or OS (Functions that do not do as they are documented to work).
Hardware problems/bugs can be intermittent.Software bugs are not...so given the exact same set of conditions they fail solid...meaning every time (with the exception of some firmware timing considerations)
Bugs are NOT:
A) Functions you want to work differently than they are designed to work today.
B) Missing capabilities you would like.
C) Design that does not allow for us to use the machine as we would like (SET file stucture issue as an example)
D) Design issues that make us do things the hard way..instead of a better way.
B) Limitations in memory, expansion, lack of new styles, lack of new sounds etc.
C) Something that you so obviously think should work one way...when they in fact work a different way...but do work.
These we call change requests or marketing requirements considerations. They are not truely bugs but some of us would see it that way...development management and programers do not.
So in summary...all bugs should be reported AND documentation provided as to how to make it fail/or how to reproduce the problem. If the development people do not have enough details as to the failure and how to reproduce it...thay will have a tough time fixing it for us.
All change requests should be documented with a scenario as to why it is an improvement and hopefully for the majority of users not just one. It would be nice if out group could put a requirements document together and include some sort of priority, even though development will do their own priority based on complexity/time/importance and if it makes the product generally better for a large group of users...AND makes them more competative through a better product.
The development team has sharp people with a limited amount of time and budget I'm sure, so I would hope we could all agree on the most important things we want/need. That won't be easy in some cases
Once again this is just my input for thought based on 40+ years in different capacities at IBM. Others certainly may have some different opinions...just tying to help us with out communications.
Lee
It is an attempt to get us all on the same page when communicating with each other, especially with Korg Development.
Based on my significant experience in hardware desgn and service, firmware design and trouble shooting ...and of course operating system tech. service and debug I offer some things to consider about BUGS.
Bugs are:
A) Documented 'functions' in a machine that do not work as described
B) Things that happen in a machine that are not supposed to while doing supported 'functions'. In other words unexpected behavior.
C) Instability in operation in general...Freezes, crashes, slow operations when they should be fast, non responsiveness to buttons/controls, etc.
D) Things (sounds for example) that have undesireable short commings of lower quality than expected or advertised is in my opinion are bugs...like some of the SAX (and other) sound problems in the PA today. This one may be borderlne as to being a bug? Maybe just more of a quality issue?
Bugs can be in the hardware (like keys that don't respond properly, intermittent switches etc) Firmware (for practical purposes is the same as hardware except it is software that directly determines hardware function) and software or OS (Functions that do not do as they are documented to work).
Hardware problems/bugs can be intermittent.Software bugs are not...so given the exact same set of conditions they fail solid...meaning every time (with the exception of some firmware timing considerations)
Bugs are NOT:
A) Functions you want to work differently than they are designed to work today.
B) Missing capabilities you would like.
C) Design that does not allow for us to use the machine as we would like (SET file stucture issue as an example)
D) Design issues that make us do things the hard way..instead of a better way.
B) Limitations in memory, expansion, lack of new styles, lack of new sounds etc.
C) Something that you so obviously think should work one way...when they in fact work a different way...but do work.
These we call change requests or marketing requirements considerations. They are not truely bugs but some of us would see it that way...development management and programers do not.
So in summary...all bugs should be reported AND documentation provided as to how to make it fail/or how to reproduce the problem. If the development people do not have enough details as to the failure and how to reproduce it...thay will have a tough time fixing it for us.
All change requests should be documented with a scenario as to why it is an improvement and hopefully for the majority of users not just one. It would be nice if out group could put a requirements document together and include some sort of priority, even though development will do their own priority based on complexity/time/importance and if it makes the product generally better for a large group of users...AND makes them more competative through a better product.
The development team has sharp people with a limited amount of time and budget I'm sure, so I would hope we could all agree on the most important things we want/need. That won't be easy in some cases
Once again this is just my input for thought based on 40+ years in different capacities at IBM. Others certainly may have some different opinions...just tying to help us with out communications.
Lee
