Is it Possible to Achieve Zero Defects?
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.