Is the value of quality determined by number of bugs found? Do you have to have a lot of bugs before your product becomes worthwhile? Or is less-polished software still worth something? We’re going to examine the answer, and show you how both extremes can be beneficial.
The first question to ask is: what do we mean by “quality of a product”? Quality can be different things for different people, which is why we should focus on the end-user. A person might consider products with no bugs superior in quality because they are easier to use and produce more reliable results.
The end-user of a software product will not notice bugs.
A bug is a defect in the software and is something that can be fixed by someone who has written it. Bugs are not bad, but when a bug is found, it means the product has less quality than it needs to have for its intended audience.
Functionality vs. Usability
Quality has two aspects: functionality and usability. Both aspects must be considered when evaluating a product — although usability can be much more important than functionality. If you’re making something to fix a problem, then that part of the software should have little or no bugs at all.
A product can have a large number of bugs (unusable) in its usability department and still be high quality because it has low functionality. Not all products are like this, but they often do. You see this most especially in the commercial world where many products are made by one person who desires to wrap up their work quickly to make a profit. It is much more common for software written by one person than other types of software because with one person there is only so much that can be accomplished.
Often those who love using a particular piece of software will take any flaws in it into consideration when judging the quality of the software. They willingly accept anything that makes the software easier and more reliable as an important quality aspect.
The other aspect of quality is functionality. Oftentimes, a number of bugs in the functionality department can be overlooked as long as the software is usable and reliable. The argument here is that a number of bugs in the usability department will reduce its functionality — which will inevitably lead to fewer sales of the product. When there are only a few bugs in the functionality department, it is still usable by users and its overall quality will remain high even if there are many usability bugs.
In this case, it makes sense to have minimal amounts of usability issues as long as they do not negatively impact the product’s overall usage or reliability. However, this does not apply to every case. If a particular piece of software has a high number of usability bugs, this could impact its functionality — and in turn, negatively impact its sales.
By understanding when the number of usability bugs will reduce the functionality of a program or product, the programmer can make decisions about when to spend time fixing these issues instead of focusing on other areas with higher priority.
In short, know when one bug is more costly than another; which is why programmers should always consider how many bugs they will have to fix per hour or per minute.
Conclusion
Considering all the above factors -The answer is Yes and No – the value of quality is NOT primarily determined by number of bugs found all factors considered. Knowing how many bugs will be in your product before it is shipped out to the customer can also help you to know when to release a particular piece of software.
This way you can time your releases for when the least number of bugs will be present — thereby maximizing the amount of quality in your program.
Having a large number of usability bugs in a program is always going to reduce its overall quality, but having too small a number will not maximize the usage that can be achieved from the software.
You might be interested in What Makes A Bug Tracking System Ineffective?