Enter Erica, a foreign exchange dealer for a major investment bank, who notices that the software she is using to measure her open U.S. dollar position seems to be misreporting the value of certain trades. Luckily she spots the defect quickly, before any monetary loss is incurred. Being distrustful of the new software, she has been keeping track of her real position on her trade blotter, so the only real cost so far is the time she has had to devote to identifying the problem and proving that it exists. But in that time, she has lost the opportunity to make an advantageous currency trade. Defect cost so far: $5,000.
Peter, a long-time programmer in the bank's Information Systems (IS) department, is given the task of finding and fixing the defect. Although Peter is not very familiar with the software in question, the original developer's highly paid contract ended a week ago, and he's lying on a beach in Hawaii. Peter takes a day to track down the bug (a misunderstanding about when Visual Basic triggers the LostFocus event of a text box) and another day to fix the program, test his fix, and run some regression tests to ensure that he has not affected any other part of the program. Defect cost so far: $6,000.
Sally is asked to check Peter's work and to write up the documentation. She notices that the same problem occurs in four other programs written by the contractor and tells Peter to fix those programs too. The fixes, testing, and documentation take another three days. Defect cost so far: $9,000.
Tony in the Quality Assurance (QA) department is the next person to receive the amended programs. He spends a day running the full set of QA standard tests. Defect cost so far: $10,000.
Finally, Erica is asked to sign off the new release for production. Because of other pressing work, she performs only the minimal testing needed to convince herself that she is no longer experiencing the same problem. The bug fix now has all the signatures necessary for production release. Total defect cost: $11,000.
But wait: statistics show that some 50 percent of bug fixes lead to the introduction of at least one new bug, which brings the statistical cost of this particular bug to over $16,000! This amount doesn't include the overhead costs of production support and implementation.
This example of a typical defect found in a production environment illustrates that the financial expenses involved in finding and fixing software bugs are often large. A commonly accepted figure in the information technology (IT) industry is that this kind of problem costs an order of magnitude more at each stage of the process. In other words, if the bug in our particular example had been found by the programmer during development, it might have cost $16 to fix. Found by a tester, the cost would have been around $160. Found by a user before it had gone into production, the cost might have been $1,600. Once the problem reaches production, the potential costs are enormous.
The most expensive bug ever reported (by Gerald Weinberg in 1983), the result of a one-character change in a previously working program, cost an incredible $1.6 billion. The jury is still out on the true cost of the Year 2000 bug, but current estimates are in the region of $600 billion worldwide. (See Chapter 8 for an in-depth treatment of the Y2K problem.) Intel spent $200 million to compensate PC owners for the now notorious Pentium bug. In 1992, a fly-by-wire passenger plane crashed during an air show, killing eleven people. The crash was traced to a bug in the software controlling the plane's flight systems. A total failure caused by bugs in a new software system installed to control the dispatch of London ambulances was judged to have directly contributed to at least one patient's death. In 1996, a London brokerage house had to pay more than $1 million to its customers after new software failed to handle customer accounts properly. The list goes on and on.
Most bugs don't have such life-or-death effects; still, the need for zero-defect or low-defect software is becoming increasingly important to our civilization. We have everything from nuclear power stations to international banking systems controlled by software, making bugs both more dangerous and more expensive. This chapter is about techniques that help to reduce or eliminate bugs in production code, especially when writing Visual Basic 6 programs.
What Are We Trying to Accomplish?
The aim of this chapter is to teach you different methods of catching bugs during Visual Basic 6 program development and unit testing, before they can reach the master source files. As programmers, we are in a unique position. First, we can learn enough about bugs and their causes to eliminate large classes of them from our programs during initial development.
Second, we are probably the only people who have sufficient knowledge of the internal workings of our programs to unit-test them effectively and thereby identify and remove many bugs before they ever reach our testers and users. Developers tend to be highly creative and imaginative people.
The challenge is to impose a certain discipline on that talent in order to attack the bug infestation at its very source. Success in meeting this challenge will give us increased user confidence, fewer user support calls and complaints, shorter product development times, lower maintenance costs, shorter maintenance backlogs, and increased developer confidence-not to mention an ability to tamper with the reality of those developers who think that a zero-defect attitude to writing code is nonproductive.
In the first part of this chapter, we'll take a look at some of the more strategic issues involved in the high bug rate currently experienced by the IT industry. We'll also look at some of the latest ideas that leading software companies such as Microsoft and Borland use to tackle those issues. Although these ideas aren't all directly related to writing code, Visual Basic developers and their managers need to understand them and the issues behind them. As Visual Basic 6 becomes more and more the corporate tool of choice in the production of large-scale projects, we are faced with a challenge to produce complex, low-defect systems within reasonable schedules and budgets. Without a firm strategic base on which to build, the game will be lost even before we start designing and coding.