Bugs vs Defects

I’ve had quite a few people ask me why I refer to software issues as defects instead of the almost ubiquitously used term "bugs". This was inspired by the writing of Watts Humphrey, in particular his book A Discipline For Software Engineering (1995) which has since been superceded by PSP: A Self-Improvement Process for Software Engineers.

When we call issues bugs it brings to mind insects slowly creeping into our software where they are not welcome. We frequently tolerate bugs (insects) in our lives, so having a few bugs in software also seems tolerable. However if we give these issues a term with a negative connotation, such as time bombs or land mines, the situation suddenly seems alot more urgent.

Why are defects more like explosive devices than bugs? Not all defects will explode in your face, but some will. They may not be fatal, but chances are they will do alot of damage.

By calling issues defects it encourages developers to take accountability for both their own and their organisations mistakes that created the defective software. This puts them in a position to take control of the software process and develop correct software.

Defects should not be thought of as minor inconveniences that will be fixed later, caught be the compiler or found in testing. We know from statistical gathering that the best way to prevent and remove defects is at the time they occur and other techniques find but a small portion of defects. Testing, for example, typically only finds 35-40% of defects. If you rely on testing alone for software quality, you aren’t going to find many defects and your time in UAT and production for finding and fixing defects will balloon.

Miriam Webster dictionary defines defective as:

This is the best description of our software and reflects the potential serious issues defective software can cause.