One hundred percent bug free software suggests a state of flawlessness that is as plausible as pigs flying in an eternal hell that has frozen over.

Hyperbole aside, our opening line is deeply rooted in one truth: there is no perfectibility when it comes to “zeros and ones”.

Organizations commit countless testing faux pas. For instance, it is a false cliché that under the “right” conditions 100% bug-free is feasible. That is pseudo logic we can’t wait to knock the bottom out of in a future rant. But first we are going to concede to our compulsion by addressing a pet peeve of ours. It is personified by what we lovingly refer to as the “I am Spartacus" moment. It will manifest in a meeting during the final stretch of a test phase under the pressures of an imminent Go / No-Go decision. It’s that moment when a middle manager, under a deep sense of defiance on behalf of the project, states the emotive claim, “I will not sign off until there are zero defects!” The only concrete value in that public assertion is in this person outing themselves as either knowing very little about testing software or having populist political motives.

If you have no hidden political agenda, we will admit that the real objective of testing can be counter-intuitive. In Fred Brooks’ software engineering bible The Mythical Man-Month, the compelling case is made that in a system that is complex there is a point at which the number of errors can no longer be reduced. And any endeavor to resolve those errors results in introducing new errors. This is a long established understanding within the software development community. And although this is not common knowledge to the general public, it should come as no surprise to most companies. Even American Idol Steve Jobs addressed it as far back as Apple's 1997 Worldwide Developers Conference.

Therefore, it is an indictment on an organization to allow “zero defects”, a toxic assertion, to be so pervasive that it fosters — if not encourages — well-meaning middle managers into an “I am Spartacus" moment. That self inflicted wound means he or she is likely to become unreceptive to factual rebuttal, as can be expected when one makes incorrect proclamations in a political environment. In such as case it is best to examine the underlying motive. If it is in good faith, we believe it is out of bounds to interpret any objection as a deceptive maneuver executed by someone that hasn’t gotten their way on the project or has made an egregious error (when done in bad faith, it is well within your right to think that).

Whether done with malice or not, the fallout from the “I am Spartacus" moment typically ends up with the organization hemorrhaging a considerable amount of time and money. Either from the pursuit of this unreachable goal or the investment in retracting the statement of our gladiator. It can take an Otto von Bismarck level of diplomacy to get everyone back in agreement, especially when expressed with conviction in a politically charge environment.

Fortunately, the “I am Spartacus” moment can be circumvented through several rudimentary project control instruments. First, the expectations as to what will be achieved during the test phase should be understood and agreed upon via well-defined exit criteria. Second, the true drivers to define boundaries preventing the "never-ending search for defects" should also be covered, such as limitations due to budget and time-to-market expectations. In this way, stakeholders more easily buy into the relevant trade-offs and the realistic conditions by which the software would be ready to launch (“zero defects” not being one of them).

Also, it would be worthwhile to remind them that this process should already be very familiar. Everyone with an Apple or Samsung device knows intimately that new products are put into the market all of the time — which include defects! So even for the giants among us, “zero defects” is not an achievable nor sought after target. “Do you really think Bill Gates ever said Microsoft will not release Windows until there are zero-defects?”, is the rhetorical question to drop the mic on.

If after all of that, someone continues to be unreceptive to the fact that software can only be tested as thoroughly as possible within the boundaries of the project, we suggest migrating the conversation to a bar — where people tend to be a little more receptive to uncomfortable truths. And if that doesn’t work, keep drinking alone, we hear wonderful things happen after that.