De Ja Vu

Ever wonder why a perfectly tested product fails for at least one quality check. Why a software program designed, developed and tested by the most superior programmer still comes up with issues when tested by the User. Or why in spite having defect prevention, quality control and a perfect software development environment still engulfs a gamut of problems when similar programming is done all the time. These questions are defended by alternate ways in today's software world and treated as an enigma. Here I explain the most fascinating of the explanations.

Project managers, audit leads, quality control representatives, subject matter experts and compliance executives all agree to the fact that any developed software program is prone to bugs without doubt. In the planning phase of a software development project, one needs to plan the number/ type/ stage/ age of defects or bugs. There are defined mechanisms for computing the number of bugs, type of bugs, and other statistical data related to defects. But can these experts explain why do we plan for defects in all development projects? These experts do agree to the existence of bugs in each program, but they do have varied explanations. One may doubt the skill or expertise of the programmer; another may state that the development environments are compellingly different. Yet another explanation may sound better is that although the technology, programming language, environment and requirements may be alike, each development is unique in its given state. But they all lack the fundamental issue of a human interference in a software development life cycle.

Electronic machines are built on the rationale of ALU - Arithmetic and Logical Unit. The computing tasks are performed by an electronic processor (device with diodes and transistors - for the lay man) with the help of this ALU. As the name indicates ALU has two important tasks Arithmetic computing and logical interpretation. And when tasks are performed by machines we are assured they would be consistent. Although unlike humans - human brains can be compared to the similar architecture. We humans compute and perform tasks on the same principle of Arithmetic and Logical aptitude. Several competitive examinations for humans - be it entrance tests for school/college education or even tests conducted for job offerings - are focused on the two aspects of Arithmetic and Logical reasoning. But unlike machines, humans have several other factors that influence the ALU of humans. Factors such as intuition, exposure to similar situations i.e. experience, concentration levels and others do influence the human ALU.

So although a programmer makes no mistake to initialize variables in 10 different programs he develops, he does make that mistake in the 11th one. I term this effect as De Ja Vu - a thing that is not visible at once but on the other instance it is. It seems as if someone has changed something suddenly to cause a defect or a bug which was never introduced before by the same person in the same situation. With all the defect prevention and the entire prior precautions one cannot avoid defects in a software development life cycle project. And hence when talked about defects we always speak towards the defect age (the difference between the time a bug is detected and then resolved), the stages when defects are detected and the arithmetic mean with upper and lower limit of the number of defects. Thus we always define our control limits for defects and never speak of a 0 – zero defect software. Because there is none!