Defect or bug – a strawman

Hi Andy
I think what you are missing here is that in Six Sigma it is the CLIENT who defines what is a defect and not the software supplier. Do you think the customer considers the failure of the SQL search to function as they expect a defect? Of course they do.
Phrases like “in this case the program has not failed – it worked correctly!” are typical of non-Six Sigma thinking.
Bugs and defects are not the same. A bug is an inadvertant mistake by a software programmer that may or may not be visible to the customer. A defect is undesired behaviour of a software program which is visible to the customer and which may or may not be associated with a software bug.
Six Sigma can help in both cases: avoiding bugs by creating more robust development and testing processes, and avoiding defects by more clearly defining and understanding the customer’s requirements.
Rgds,Adrian

I agree with your customer view, however if a bug requires rework,  I consider it a defect.
Stevo
 

Andy,
 
I usually don’t get involve in these serious conversations because I have neither the experience nor the education to add much value.  But I’m on cold medicine so here goes:
 
If you look at the product itself, then I can see both sides.  However if you look at the process holistically, where does the process end?  To me, it ends with a customer knowing how to use our product well.  If our training material is not doing its job or if we haven’t Poka Yoked it well, then we still hold some of the responsibility.
 
Thank god for the good drugs,
 
Stevo

I think you want to be a little careful in throwing around terms like ‘bug’ and ‘defect’ as they relate to software.  Software types have very specific meaning for the term ‘defect’, and Six Sigma software shops count defects, most of which (hopefully) never reach the customer.
In software development, a failure to meet requirements (which for some operations might be some internal requirement) is called an error.  An error which escapes the phase is called a defect, and a defect which escapes to the customer is called a released defect.  Managing these escape rates is an important aspect of software development, and a place where Six Sigma can be, and has been, applied with considerable success.  Avoiding the errors in the first place has tended to be somewhat less successful.
Bug is an imprecise term which generally isn’t used by shops which are paying attention to quality.  It tends to be more in vogue among garage shops and kids playing in the basement.
And I am absolutely at odds with your statement “I also disagree that the use of Six Sigma can offer much towards the ‘creation’of robust software development”
Software development is a process, like any other process, and like any other process, it can be improved.  The way we improve processes is with Six Sigma.
But it goes beyond that.  Software developers use DFSS as their process for developing robust software.  DFSS is quite similar to the traditional SDLC, but offers more robust tools at every step along the way.
Certainly different tools are used in software development with a different frequency than in manufacturing, just as different tools tend to be used in any transactional process.
For example a gage R&R is often impossible to perform for many transactional measurements. Get over it, move on.  On the other hand, tools like ABC/BOC or logistic regression tend to be used more frequently.  But the process is the same.
I might even go so far as to argue that the opportunities are not nearly as rampant in ‘testing’ as they are in development.  The money lying around in development waiting to be picked up is absolutely amazing.
–McD
 
 

Andy,
It IS infact, the Customer who defines specifications and what constitutes a defect.
It doesn’t matter if your process is pouring a cup of coffee, writing code, or building a thermonuclear warhead.   same-same.
VoC drives all activity.   Until you recognize this, nothing productive can come from debating the minutae and floating examples…
Seriously, The Customer is King.   If these 3 criteria are not ALL met, whether dealing with widgets, or with services/transactions, it is Non Value-added:
1) Does the Customer care? (or are they willing to pay for it?)
2) Was there a physical transformation to the product or service (or code)
3) Was it done right the first time?
All or none.   I don’t know if a Customer really wants to pay for glitchy software outside of a deliberate testing environment, or white-hat hack.

Hi Andy,
I would argue that the example you gave about querying O’Toole in a database is simply a defect. The customer expectation (whether stated in the requirements or not) will be to be able query for “any valid” name. If the requirements capture this correctly by enumerating all the characters that are possible in a “valid” name then this will be a defect where the SW did not implement the requirement correctly. If the requirements failed to capture this, then it will be a defect in the requirements.
In either case what will happen is that the defect will be fixed and a patch or a new version of the SW will be delivered (eventually :) ).
Personally I use the defect and bug terms interchangeably, but I could also agree with the interpretation that a defect is something where the system needs to exchanched (as in your phone example) and a bug is something where the SW will be exchanged (upgraded, patched).
Regards
Sandor

Hi,
just two quick observations:
I would be wary of the term “deviation from requirements” as a synonim for bugs or defects . In fact quite a number of bugs come from defects in the requirements – those guys writing them are only humans after all :-)).
The other point I’d like to make is that SW development does NOT end at delivery. In a good quality product 60 to 80% of the development budget will be spent after the “final” delivery  for new versions, patches, bug-fixes etc.
For a crappy product it will be much less, because no one will care to propose changes or report bugs.
Regards
Sandor

Hi Anil,
I guess both ways of looking at it can be valid, depending on the circumstances. In a big project there are so many dependencies and limitations that depend on past history that I’d be reluctant to consider it a “new” process every time time we do a new release. I’ve also seen a small company go bankrupt because they thought that the development work ends at the final delivery – and did not budget for the 60-80% that came afterwards.
On the other hand, for many purposes, like process improvement for example, it could be very helpful to see the development process the way you propose.
regards
Sandor