Squashing Bugs at the Source

What everyone had always suspected about bugs was set in stone in 1994 when Kaplan, Clark, and Tang published their findings on the comparative costs of tackling bugs (Secrets of Software Quality: 40 Innovations from IBM, McGraw-Hill, 1994J. Their findings are frightening, particularly as their research was conducted on the corporation that has more experience in programming than anyone, IBM. They found that resolving a bug once a program has been released may cost a thousand times more than squashing it at birth. In one case, programmers spent 7,053 hours inspecting 200,000 lines of code, preempting 3,112 potential defects at the design stage. Kaplan, Clark, and Tang calculated programmers' time at $40 per hour (1993 rates). The total expense amounted to $282,120, or $90.65 per defect. Compare this to their findings about putting things right after the product is shipped. Assume that the programmers have the incidence of bugs down to 1 per 1,000 lines of code (lower than average). Once bugs get into the field, the cost of rectification was calculated at $25,000 per fix. The bill, $5 million, was almost 18 times the cost of sorting the problems out during development.


Table 9-1 What Bugs Cost to Fix


Unit Cost











Development Test



Systems Test



In Operation



As you can see from looking at Table 9-1, you have no choice. If you want to get into business, let alone stay in it, bugs must be fixed at the earliest opportunity. Stark as this precept is, there is an even bigger lesson: Prevention is better than cure. However, as easy as it is for management to say that, it is notoriously difficult for programmers to deliver.

If some of the biggest, most experienced, most efficient names in the computer world have this sort of trouble, you can't expect to get off scot-free; but this doesn't mean you can't also be successful.

In computing, quality control is centered around the idea of making a program perfect. In practice this comes down to designing, constructing, detecting, measuring, and fixing methods that ensure that as many errors as possible can and will be removed at the earliest stage. It's not that bugs prevent programs from working in the end; it's the drain on resources. If you don't build quality gates into development from the outset, costs will skyrocket and the product will bomb.

How Bugs Became Bugs

Before looking at how you can optimize the process of creation, you should know why bugs in the computing world are called bugs. Not a lot of people know this.

When Harvard University was developing its Mark II Computer in late 1945, production ground to a halt. On inspection they discovered that a moth had flown between the relays of the valves that powered the early relays. The time was 15:45, the date September 9, 1945, and the person no other than Commodore Grace Hopper, who apart from being a stickler for program structure, is one of the pantheons of computer greats. She went on to help develop COBOL, the first compiler, and program Harvard's original Ml and MII computers.

The first computer bug really was a bug—nowadays they're all manmade.

0 0

Post a comment