Is it Possible to Achieve Zero Defects?

According to Independent Eclipse Consultant Madhu Samuel, it depends on who you ask that question to.

In Samuel’s experience, a manager is likely to
reply: “Defects are induced because of the carelessness of the
engineers.”

Whereas the engineer is likely to reply: “Its not possible to
achieve zero defects, even though we can strive to reduce the
defect count. We have even created tools to track down the bug
count ….”

And the customer is likely to point to the price tag and demand
zero defects: “You are so expensive. If your product is not defect
free, then why should I invest such a huge amount for your
service?”

All three parties make valid points. An engineer building a
complex software system cannot imagine and test every possible
scenario for that software system. Logically, it is asking the
impossible. And we, as customers, know how frustrating it is to pay
for something that doesn’t work the way we want it to. As paying
customers, we expect perfection, even if common sense dictates that
software is never going to be bug-free. Likewise, the manager who
regularly comes into contact with irate customers, is going to put
pressure on the engineer to achieve the impossible ideal.

But, how do you get a bug free system? Samuel proposes a
mathematical formula. The software system has ‘n’ number of states.
This ‘n’ number of states, should be tested against ‘n’ number of
test cases, to ensure that the software system has zero
defects.

The problem is that even a simple program with a primitive
variable, has far too many different states to test. In practice,
it is virtually impossible to test ‘n’ number of states against ‘n’
number of test cases. “You (would) need unacceptable duration of
time and patience to do a complete exhaustive testing. By the time
you finish your testing, years would’ve passed.” So, the engineer
compromises and tests a handful of generic conditions, even though
there is always the chance that a bug is hidden between these
generic conditions.

Samuel concludes that the pressures of keeping a product’s
time-to-market cycle low means that software will continue to ship
with hidden bugs. He has a point. Time-to-market is a big buzz word
– stick ‘reduce’ in front of it on a Google search, and you’ll be
tripping over products and companies all promising to reduce the
time it takes to build and ship software. Logically, if you’re
shipping software as quickly as possible, then bugs are always
going to slip through.

But, if zero defects are the impossible ideal, then how can you
at least reduce the number of defects? In Samuel’s opinion, it is
all down to resources. Recruit team members who are passionate
about their work, and service them with the best software
infrastructure, and the best working infrastructure to help them
relax, such as flexible working hours, a quiet working environment,
and the option of working from home. Creating a culture of trust
and knowledge sharing will also be beneficial; a big part of this
is not blaming an engineer for a bug and the absence of
creativity-stifling micro management.

Zero defects isn’t a realistic goal, but Samuel’s proposition of
supporting the engineer in their efforts to deliver software with
as few bugs as possible, is a valid one. Shifting the focus away
from unrealistic bug-free software, and channelling that energy
into making almost-bug-free software, can only benefit the three
parties involved: the customer, the manager and, ultimately, the
software engineer themselves.